在创建数据库的时候，有了一个疑问，在一般真实项目开发的时候，数据库表于表之间会设置关联吗？，比如说外键之类的。
我看了有些框架，比如说若依框架的数据库，发现好像并没有设置外键关联，如果说一般不设置关联，那么数据库关联有什么用呢？什么时候会用到？
外键不会放在数据库进行维护, 外键可以理解为一种约束, 现在已经不是很早以前了, 数据量不大, 数据库压力不大, 放到数据库维护, 现在数据库压力一般都比较大的, 因此, 外键约束已经在现在的程序中被废弃了, 而是采用程序来约束.
包过级联删除等, 都是程序操作, 已和外键无关.
第二, 表之间的关联没有强制关联一说, 因为有了强制关联, 比如: 外键, 数据库相当于做了程序本身要做的事情(多做了), 因此, 现在都是职责划分, 表关联其实就是程序上的需要, 因此, 在程序中解决, 而非强制关联
实际项目中,是否设置表关联需要综合考虑，一般不设置，设置外键关联好处和弊端：
好处：保证数据的完整性和一致性，查询时利用关联进行连接查询
弊端：额外占用存储空间并降低插入和更新的效率，增加表与表之间的依赖,给维护带来一定难度
在实际开发中，使用外键会增加维护复杂度和成本，所以不建议使用。一般使用id与id之间的连表查询进行关联。
楼上几位说的都没有问题，通俗的讲，就是外键约束是曾经一群做数据库设计的工程师们，想着如果不同表之间的数据如果独立的插入没有关联项和约束，那么会出现不一致的问题可能导致数据库数据不完整。所以为了保证数据的完整性和一致性，然后提出外键约束这个概念。所以上面的回答基本上没问题，但是现实中，你会发现很多老系统包括银行系统，ERP，SAP 等等企业级的软件产品，还在准守。但是互联网级别的2C产品就基本上不在准守了。这个代价上面两位已经说了。
那么为什么会有系统还在准守这种影响性能的外键关系呢，我举个例子你看额能理解了。
假设银行的数据库中有两张表，一张是 accounts 表，存储银行客户的账户信息，包括账户号、姓名、地址、电话等；另一张是 transactions 表，存储账户的交易信息，包括交易号、账户号、交易时间、交易金额等。在这个数据库中，transactions 表中的账户号是 accounts 表中的主键，因此 transactions 表中的账户号应该作为外键与 accounts 表建立关联。这个外键约束的作用是，保证每个交易都必须属于一个有效的账户，防止出现账户不存在或账户号错误的情况。我们想象如果没有外键约束，应用层如果无法保证。可能会出现交易记录中的账户号与 accounts 表中的账户号不匹配的情况，导致数据的不一致性和错误。