“在添加记录之前，检查对应的记录是否存在于另一个表中”是业务逻辑。

这里有一些你不希望在数据库中使用它的原因:

If the business rules change, you have to change the database. The database will need to recreate the index in a lot of cases and this is slow on large tables. (Changing rules include: allow guests to post messages or allow users to delete their account despite having posted comments, etc). Changing the database is not as easy as deploying a software fix by pushing the changes to the production repository. We want to avoid changing the database structure as much as possible. The more business logic there is in the database the more you increase the chances of needing to change the databae (and triggering re-indexing). TDD. In unit tests you can substitute the database for mocks and test the functionality. If you have any business logic in your database, you are not doing complete tests and would need to either test with the database or replicate the business logic in code for testing purposes, duplicating the logic and increasing the likelyhood of the logic not working in the same way. Reusing your logic with different data sources. If there is no logic in the database, my application can create objects from records from the database, create them from a web service, a json file or any other source. I just need to swap out the data mapper implementation and can use all my business logic with any source. If there is logic in the database, this isn't possible and you have to implement the logic at the data mapper layer or in the business logic. Either way, you need those checks in your code. If there's no logic in the database I can deploy the application in different locations using different database or flat-file implementations.

它们会使删除记录变得更加麻烦——当其他表中存在外键违反约束的记录时，您就不能删除“主”记录。可以使用触发器进行级联删除。

如果不明智地选择主键，则更改该值将变得更加复杂。例如，如果我有我的“客户”表的PK作为人的名字，并使该键在“订单”表中为FK，如果客户想更改他的名字，那么这是一个巨大的痛苦……但这只是粗制滥造的数据库设计。

我相信使用火密钥的优点大于任何假定的缺点。

One time when an FK might cause you a problem is when you have historical data that references the key (in a lookup table) even though you no longer want the key available. Obviously the solution is to design things better up front, but I am thinking of real world situations here where you don't always have control of the full solution. For example: perhaps you have a look up table customer_type that lists different types of customers - lets say you need to remove a certain customer type, but (due to business restraints) aren't able to update the client software, and nobody invisaged this situation when developing the software, the fact that it is a foreign key in some other table may prevent you from removing the row even though you know the historical data that references it is irrelevant. After being burnt with this a few times you probably lean away from db enforcement of relationships. (I'm not saying this is good - just giving a reason why you may decide to avoid FKs and db contraints in general)

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

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

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

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

这会导致不同的问题:

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

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

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

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

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

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

我一直认为不用它们是懒惰的表现。我被教导应该一直这样做。但后来，我没有听乔尔的讨论。他也许有充分的理由，我不知道。