必须设置外键VS不要设置外键的争执

数据库表到底要不要设置外键束缚，始终具备十分大的争议。我认为齐全没有必要非黑即白，存在即正当。

这两种争执的产生本源在于它们都有各自的应用场景和理由，并不是纯理论的空想。

所以最好的形式是依据我的项目类型、业务场景进行决策，甚至能够两种形式混合应用，才是最好的。

例如对于证券、股票、保险、银行等金融行业，应该设置外键保证数据的一致性更加重要，而对于互联网行行业的衣食住行则能够采纳无外键设计，谋求更高的性能和更快的迭代速度。

数据库表不设置外键会有哪些问题？

  1. 数据完整性问题

    短少外键最次要的问题是数据库不能强制进行完整性束缚查看，如果在业务程序中没有正确处理，则可能会导致数据不统一。例如银行、证券、保险等金融行业，每一个账户的金额都不能出错，一旦呈现数据不统一就是灾难性的问题。

  2. 表之间的关系不清晰

    无奈间接通过外键来梳理表之间的关联关系，对于新接触我的项目的人员会十分困难。对于一些大型的简单我的项目，没有外键束缚，梳理不清表之间的关系也是一种劫难。

如果数据库表不设置外键会有哪些益处？

  1. 对性能具备较大的晋升

    在表上领有流动的外键能够进步数据品质，但会影响插入、更新和删除操作的性能。在这些工作之前，数据库须要查看它是否违反数据完整性。这就是为什么一些架构师和DBA齐全放弃外键的起因。数据仓库和剖析数据库尤其如此，这些数据仓库和剖析数据库不以交易方式（一次一行）解决数据，而是批量解决数据。性能是数据仓库和商业智能的所有。

  2. 旧数据和脏数据更加利于存储

    许多数据库在设计时须要存储来自旧数据库和遗留数据，这些数据可能对数据品质和完整性没有那么严格。为了可能包容旧的脏数据，架构师能够抉择（1）清理和转换遗留数据，这要消耗很大的人力老本。（2）放弃在数据库级别上强制执行参照完整性。一些打包的ERP和CRM应用程序也应用这种办法。

  3. 全表从新加载的时候会更加不便

    一些数据库，如数据仓库，分段或接口数据库，须要常常从内部从新加载数据。这会导致从新加载时数据不统一（在父表为空的状况下，子表可能已满载）。这能够通过在从新加载时禁用外键来绕过。然而，这引入了额定的逻辑和复杂性以及另一个失败点。如上所述，对性能有负面影响。通常，老本大于收益，开发人员不必放心外键。

  4. 采纳更高层次的框架来解决束缚问题

    一些应用程序应用编程框架，在物理数据库之上创立另一个逻辑层。开发人员不应用插入或更新语句来批改数据，而应用API或者框架在后盾执行所有操作。ORM（对象关系映射）框架或Ruby on Rails框架就是这种状况。这些工具负责参照完整性，并与RDBMS一起创立更高级别的数据库引擎。这些框架能够本人创立数据库表，而不总是创立外键。应用这些工具的开发人员很少会烦扰主动生成的模式，并且不须要外键。

  5. 激励翻新，对更改凋谢

    这种观点认为，减少外键会升高设计者的优化欲望，因为批改过程较为麻烦，所以限度了设计人员的翻新思维。

  6. 架构师或设计师的懈怠心理失去满足

    创立表的时候只有本人心里晓得他们的关联关系就好了，不须要做那么多额定的设置，并且一旦须要调整设计就会非常繁琐，所以有很多设计人员就不再设置外键了。

  7. 放弃模型的复杂度，保护集体位置

    每一个设计者都心愿本人是不可代替的，设计出简单的数据模型，而不设置外键束缚，这样就只有本人分明他们的关联关系，只有本人可能进一步保护，出了问题也只有本人最分明，从而能够放弃本人的竞争力。这种想法看似邪恶，然而这样做的的确大有人在。