对我来说，如果您想要遵循ACID标准，那么拥有外键以确保引用完整性是至关重要的。

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

我听到的观点是前端应该有这些业务规则。当您一开始就不应该允许任何破坏约束的插入时，外键会“增加不必要的开销”。我同意吗?不，但我一直都是这么听说的。

编辑:我猜他指的是外键约束，而不是外键这个概念。

如果您绝对确信底层数据库系统将来不会改变，我将使用外键来确保数据完整性。

但在现实生活中，还有一个完全不使用外键的很好的理由:

您正在开发一个产品，该产品应该支持不同的数据库系统。

如果您正在使用实体框架(Entity Framework)，该框架能够连接到许多不同的数据库系统，那么您可能还希望支持“开源免费”的无服务器数据库。并非所有这些数据库都支持外键规则(更新、删除行……)。

这会导致不同的问题:

1)。在创建或更新数据库结构时，可能会遇到错误。可能只有无声错误，因为数据库系统忽略了外键。

2)。如果依赖于外键，则可能在业务逻辑中较少甚至不进行数据完整性检查。现在，如果新的数据库系统不支持这些外键规则，或者只是以不同的方式运行，那么您必须重写业务逻辑。

您可能会问:谁需要不同的数据库系统?当然，不是每个人都能负担得起或想要在他的机器上安装一个完整的SQL-Server。这是软件，需要维护。其他人已经在其他一些DB系统上投入了时间和金钱。无服务器数据库非常适合只有一台机器上的小客户。

没有人知道，所有这些DB系统是如何运行的，但是您的业务逻辑，包括完整性检查，总是保持不变的。

数据结构设计的一个好的原则是确保表或对象的每个属性都服从于一个很好理解的约束。这很重要，因为如果您或您的程序可以依赖数据库中的有效数据，那么就不太可能出现由坏数据引起的程序缺陷。您还可以花费更少的时间来编写处理错误条件的代码，并且更有可能预先编写错误处理代码。

在许多情况下，这些约束可以在编译时定义，在这种情况下，您可以编写一个筛选器来确保属性总是在范围内，或者尝试保存属性失败。

然而，在许多情况下，这些约束可以在运行时更改。例如，您可能有一个“cars”表，其属性为“colour”，初始值为“red”、“green”和“blue”。在程序执行期间，可以将有效的颜色添加到初始列表中，并且添加的新“汽车”可以采用最新颜色列表中的任何颜色。此外，您通常希望这个更新的颜色列表在程序重新启动后仍然有效。

To answer your question, it turns out that if you have a requirement for data constraint that can change at run-time, and those changes must survive a program restart, foreign keys are the simplest and most concise solution to the problem. The development cost is the addition of one table (e.g. "colours", a foreign key constraint to the "cars" table, and an index), and the run-time cost is the extra table lookup for the up-to-date colours to validate the data, and this run-time cost is usually mitigated by indexing and caching.

如果您不使用外键来满足这些需求，那么您必须编写软件来管理列表、查找有效的条目、将其保存到磁盘、如果列表很大的话有效地组织数据、确保对列表的任何更新都不会破坏列表文件、在有多个读取器和/或写入器的情况下提供对列表的串行访问，等等。例如，你需要实现大量的RDBMS功能。

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

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

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