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

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

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

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

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

没有充分的理由不使用它们……除非孤行对你来说不是什么大问题。

外键对于任何关系数据库模型都是必不可少的。

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

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

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

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

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

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

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

这是一个教养问题。如果在您的教育或职业生涯中，您曾花时间维护数据库(或与有才华的人密切合作)，那么实体和关系的基本原则就会在您的思维过程中根深蒂固。这些基本知识包括如何/何时/为什么在数据库中指定键(主键、外键和备选键)。这是第二天性。

If, however, you've not had such a thorough or positive experience in your past with RDBMS-related endeavors, then you've likely not been exposed to such information. Or perhaps your past includes immersion in an environment that was vociferously anti-database (e.g., "those DBAs are idiots - we few, we chosen few java/c# code slingers will save the day"), in which case you might be vehemently opposed to the arcane babblings of some dweeb telling you that FKs (and the constraints they can imply) really are important if you'd just listen.

大多数人小时候都被教育刷牙很重要。没有它你能过吗?当然，但在某个时候，如果你每顿饭后都刷牙，那么你的牙齿就会减少。如果妈妈和爸爸们有足够的责任心，把数据库设计和口腔卫生都包括在内，我们就不会有这样的对话了。: -)