我记得在播客014中听到Joel Spolsky提到他几乎从未使用过外键(如果我没记错的话)。然而，对我来说，它们对于避免数据库中的重复和后续数据完整性问题非常重要。
人们是否有一些可靠的理由(以避免与Stack Overflow原则一致的讨论)?
编辑:“我还没有创建外键的理由，所以这可能是我真正建立一个外键的第一个理由。”
当前回答
我同意德米特里的话，但要补充一点。
我在一个批处理计费系统中工作，需要在30多个表中插入大量的行。我们不允许做数据泵(Oracle)，所以我们必须做批量插入。这些表上有外键，但我们已经确保它们不会破坏任何关系。
在插入之前，我们禁用外键约束，这样Oracle就不会一直进行插入。插入成功后，我们重新启用约束。
PS:在一个大型数据库中，一条记录有许多外键和子行数据，有时外键可能不好，您可能希望禁止级联删除。对于在计费系统中的我们来说，如果进行级联删除，将花费太长时间，并且对数据库造成太大负担，因此我们只是在主驱动程序(父)表上使用一个字段将记录标记为坏记录。
其他回答
我也听过这种说法——有些人忘记在外键上放索引，然后抱怨某些操作很慢(因为约束检查可以利用任何索引)。所以总结一下:没有好的理由不使用外键。所有现代数据库都支持级联删除，所以…
在这里回答问题的许多人都过于关注通过引用约束实现的引用完整性的重要性。在具有引用完整性的大型数据库上工作性能不佳。Oracle似乎特别不擅长级联删除。我的经验法则是，应用程序永远不应该直接更新数据库，而应该通过存储过程更新。这将代码库保存在数据库中，并意味着数据库保持其完整性。
在许多应用程序可能正在访问数据库的地方，由于引用完整性约束确实会出现问题，但这取决于控件。
还有一个更广泛的问题，应用程序开发人员可能有非常不同的需求，而数据库开发人员可能并不那么熟悉。
像许多事情一样，这是一种权衡。这是一个你想在哪里进行验证数据完整性的工作的问题:
(1)使用外键(单点配置为一个表，功能已经实现，经过测试，证明有效)
(2)把它留给数据库的用户(可能多个用户/应用程序更新同一个表)，这意味着更多潜在的故障点和测试的复杂性)。
数据库执行(2)更有效，使用(1)更容易维护，风险更小。
有一个很好的理由不使用它们:如果你不了解它们的作用或如何使用它们。
在错误的情况下，外键约束可能导致事故的瀑布式复制。如果有人删除了错误的记录，恢复它可能会成为一项艰巨的任务。
同样，相反，当您需要删除某些内容时，如果设计不当，约束可能会导致各种锁阻止您的操作。
使用外键的其他原因: —可以更好地重用数据库
不使用外键的其他原因: —您试图通过减少重用来锁定客户。
