我记得在播客014中听到Joel Spolsky提到他几乎从未使用过外键(如果我没记错的话)。然而，对我来说，它们对于避免数据库中的重复和后续数据完整性问题非常重要。
人们是否有一些可靠的理由(以避免与Stack Overflow原则一致的讨论)?
编辑:“我还没有创建外键的理由，所以这可能是我真正建立一个外键的第一个理由。”
当前回答
像许多事情一样，这是一种权衡。这是一个你想在哪里进行验证数据完整性的工作的问题:
(1)使用外键(单点配置为一个表，功能已经实现，经过测试，证明有效)
(2)把它留给数据库的用户(可能多个用户/应用程序更新同一个表)，这意味着更多潜在的故障点和测试的复杂性)。
数据库执行(2)更有效，使用(1)更容易维护，风险更小。
其他回答
对我来说，如果您想要遵循ACID标准，那么拥有外键以确保引用完整性是至关重要的。
我同意德米特里的话，但要补充一点。
我在一个批处理计费系统中工作，需要在30多个表中插入大量的行。我们不允许做数据泵(Oracle)，所以我们必须做批量插入。这些表上有外键，但我们已经确保它们不会破坏任何关系。
在插入之前，我们禁用外键约束，这样Oracle就不会一直进行插入。插入成功后，我们重新启用约束。
PS:在一个大型数据库中，一条记录有许多外键和子行数据，有时外键可能不好，您可能希望禁止级联删除。对于在计费系统中的我们来说，如果进行级联删除，将花费太长时间，并且对数据库造成太大负担，因此我们只是在主驱动程序(父)表上使用一个字段将记录标记为坏记录。
验证外键约束需要一些CPU时间，因此有些人省略外键以获得额外的性能。
我听到的观点是前端应该有这些业务规则。当您一开始就不应该允许任何破坏约束的插入时，外键会“增加不必要的开销”。我同意吗?不，但我一直都是这么听说的。
编辑:我猜他指的是外键约束，而不是外键这个概念。
有一个很好的理由不使用它们:如果你不了解它们的作用或如何使用它们。
在错误的情况下，外键约束可能导致事故的瀑布式复制。如果有人删除了错误的记录，恢复它可能会成为一项艰巨的任务。
同样，相反，当您需要删除某些内容时，如果设计不当，约束可能会导致各种锁阻止您的操作。
