我记得在播客014中听到Joel Spolsky提到他几乎从未使用过外键(如果我没记错的话)。然而，对我来说，它们对于避免数据库中的重复和后续数据完整性问题非常重要。
人们是否有一些可靠的理由(以避免与Stack Overflow原则一致的讨论)?
编辑:“我还没有创建外键的理由，所以这可能是我真正建立一个外键的第一个理由。”
当前回答
我听到的观点是前端应该有这些业务规则。当您一开始就不应该允许任何破坏约束的插入时，外键会“增加不必要的开销”。我同意吗?不，但我一直都是这么听说的。
编辑:我猜他指的是外键约束，而不是外键这个概念。
其他回答
@ emphasis——这正是导致维护噩梦的心态。
为什么，哦，为什么要忽略声明性引用完整性(其中数据至少可以保证一致)，而支持所谓的“软件强制”，这充其量是一种薄弱的预防措施。
跨应用程序生命周期的可维护性和稳定性如何?大多数数据的生命周期都比使用它的应用程序长。关系和数据完整性非常重要，不能寄希望于下一个开发团队在应用程序代码中做出正确的处理。如果您没有使用过不尊重自然关系的脏数据的db，那么您将会使用。数据完整性的重要性将变得非常清楚。
验证外键约束需要一些CPU时间，因此有些人省略外键以获得额外的性能。
如果您绝对确信底层数据库系统将来不会改变，我将使用外键来确保数据完整性。
但在现实生活中，还有一个完全不使用外键的很好的理由:
您正在开发一个产品，该产品应该支持不同的数据库系统。
如果您正在使用实体框架(Entity Framework)，该框架能够连接到许多不同的数据库系统，那么您可能还希望支持“开源免费”的无服务器数据库。并非所有这些数据库都支持外键规则(更新、删除行……)。
这会导致不同的问题:
1)。在创建或更新数据库结构时，可能会遇到错误。可能只有无声错误，因为数据库系统忽略了外键。
2)。如果依赖于外键，则可能在业务逻辑中较少甚至不进行数据完整性检查。现在，如果新的数据库系统不支持这些外键规则，或者只是以不同的方式运行，那么您必须重写业务逻辑。
您可能会问:谁需要不同的数据库系统?当然，不是每个人都能负担得起或想要在他的机器上安装一个完整的SQL-Server。这是软件，需要维护。其他人已经在其他一些DB系统上投入了时间和金钱。无服务器数据库非常适合只有一台机器上的小客户。
没有人知道，所有这些DB系统是如何运行的，但是您的业务逻辑，包括完整性检查，总是保持不变的。
它们会使删除记录变得更加麻烦——当其他表中存在外键违反约束的记录时，您就不能删除“主”记录。可以使用触发器进行级联删除。
如果不明智地选择主键，则更改该值将变得更加复杂。例如，如果我有我的“客户”表的PK作为人的名字，并使该键在“订单”表中为FK，如果客户想更改他的名字，那么这是一个巨大的痛苦……但这只是粗制滥造的数据库设计。
我相信使用火密钥的优点大于任何假定的缺点。
