以编程方式强制执行外键的优缺点

Question

仅仅通过让数据库强制执行外键，在开发方面造成了很多麻烦。特别是在单元测试期间，由于外键约束我无法删除表，我需要按照外键约束警告不会被触发的顺序创建表。实际上，我没有看到让数据库强制执行外键约束的重点。如果应用程序设计得当，除了select查询之外，不应该有任何手动数据库操作。我只是想确保通过不在数据库中使用外键约束并将其完全留给应用程序负责来确保我不会陷入困境。我错过了什么吗？

P.S。如果底层域对象的结构已被修改，我的真实单元测试（不是使用模拟的那些）将丢弃现有的表。

Answer 1

根据我的经验，如果您不在数据库中强制执行外键，那么最终（假设数据库相对较大并且使用频繁）您将最终得到孤立记录。这可能在很多方面发生，但似乎总会发生。

如果索引正确，外键不应该有任何性能优势。

所以问题是，在您的数据库中拥有孤立记录的潜在损害/麻烦/支持成本/财务成本是否超过了开发和测试的麻烦？

根据我的经验，对于业务应用程序，我总是使用外键。使构建脚本正常工作只需要一次性设置成本，数据稳定性将超过应用程序生命周期内的费用。

Answer 2

在数据库中强制执行规则的关键在于它是声明性的 - 例如你不必编写大量的代码来处理它。

就您的单元测试而言，只需按正确的顺序删除表。你只需编写一个函数来做一次。

Answer 3

您在开发中遇到的问题不应该推动数据库设计。不断重建数据库是开发人员用例，而不是客户用例。

此外，数据库约束有助于您的应用程序。你永远不知道你的客户会尝试做什么。不要过度，但你需要一些。

Answer 4

您似乎可以依赖您的应用程序来遵循隐含的规则，但除非您强制执行这些规则，否则最终会有人犯错误。
或者也许5年后，有人会对“不再需要的”旧记录进行整理，并且没有意识到其他表中的数据仍然引用它们。然后几天/周后你或你的继任者得到了有趣的工作，试图修复数据库所涉及的混乱。 ： - ）

Answer 5

在上一个关于SO的问题中，这是一个很好的讨论：What's wrong with foreign keys?。 [编辑]：如果任何一个缺点适用，则参数是使非强制外键获得一些专业人员。

Answer 6

  

如果申请是正确的   设计不应该有任何   手动数据库操作其他   而不是选择查询

什么？你喝的是什么样的koolaid？存在大多数数据库应用程序来操纵数据库中的数据而不仅仅是为了查看它。通常，应用程序的整个目的是添加新订单或创建新客户记录或记录客户服务电话等。

外键用于数据完整性。数据完整性对于能够以任何可靠性使用数据至关重要。没有数据完整性的数据库是无用的，可能导致公司赔钱。这超越了以自我为中心的观点，即不需要FK，因为它们使开发变得更加复杂。数据比运行测试的便利性要重要得多（可以写入FK）。