在这里回答问题的许多人都过于关注通过引用约束实现的引用完整性的重要性。在具有引用完整性的大型数据库上工作性能不佳。Oracle似乎特别不擅长级联删除。我的经验法则是，应用程序永远不应该直接更新数据库，而应该通过存储过程更新。这将代码库保存在数据库中，并意味着数据库保持其完整性。

在许多应用程序可能正在访问数据库的地方，由于引用完整性约束确实会出现问题，但这取决于控件。

还有一个更广泛的问题，应用程序开发人员可能有非常不同的需求，而数据库开发人员可能并不那么熟悉。

我经常使用它们，但后来我为金融系统制作数据库。数据库是应用程序的关键部分。如果金融数据库中的数据不是完全准确的，那么无论你在代码/前端设计上投入多少精力都没有意义。你只是在浪费时间。

还有一个事实是，多个系统通常需要直接与数据库接口-从其他系统只是读取数据(Crystal Reports)到系统插入数据(不一定使用我设计的API;它可能是由一个刚刚发现VBScript并拥有SQL框SA密码的愚蠢的经理编写的)。如果数据库不能像白痴一样证明它可能是，好吧，再见数据库。

如果您的数据很重要，那么可以使用外键，创建一套存储过程来与数据交互，并创建最强大的DB。如果您的数据不重要，那么为什么要开始创建数据库呢?

澄清数据库是一个没有主键或外键的商业数据库示例。

http://www.geekinterview.com/question_details/18869

有趣的是，技术文档花了很大的篇幅来解释表是如何关联的，用什么列来连接它们等等。

换句话说，它们本可以使用显式声明(DRI)连接表，但它们选择不这样做。

因此，澄清数据库充满了不一致，性能不佳。

但我认为它使开发人员的工作更容易，不必编写代码来处理引用完整性，例如在删除或添加之前检查相关行。

我认为，这就是关系数据库中没有外键约束的主要好处。它使开发变得更容易，至少从不顾一切的角度来看是这样。

我还认为外键在大多数数据库中是必要的。唯一的缺点(除了强制一致性带来的性能损失之外)是使用外键允许人们编写假定存在功能外键的代码。这绝不应该被允许。

例如，我看到有人编写了一些代码，将插入插入引用表中，然后尝试将插入插入引用表中，而不验证第一次插入是否成功。如果稍后删除外键，则会导致数据库不一致。

您也不能在更新或删除时假设特定的行为。无论是否存在外键，您仍然需要编写代码来执行您想要的操作。如果您假设删除是级联的，但实际上它们不是级联的，那么您的删除将失败。如果您假定对引用列的更新被传播到引用行，但实际上没有，那么您的更新将失败。出于编写代码的目的，最好不要使用这些特性。

如果打开了这些特性，那么您的代码无论如何都会模仿它们，并且会损失一些性能。

所以，总结....如果需要一致的数据库，外键是必不可少的。在您编写的代码中，永远不应假定外键存在或起作用。

我不得不在这里第二多的评论，外键是必要的项目，以确保你有完整的数据。ON DELETE和ON UPDATE的不同选项将允许你绕过一些人们在这里提到的关于它们的使用的“下降”。

我发现在我99%的项目中，我会使用FK来加强数据的完整性，然而，在很少的情况下，我的客户必须保留他们的旧数据，不管它有多糟糕....但后来我花了很多时间写代码，只得到有效的数据，所以它变得毫无意义。

我同意前面的答案，因为它们对维护数据一致性很有用。然而，Jeff Atwood几周前发表了一篇有趣的文章，讨论了规范化和一致性数据的利弊。

简而言之，在处理大量数据时，非规范化数据库可以更快;你可能不关心精确的一致性取决于应用程序，但它迫使你在处理数据时更加小心，因为DB不会。