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

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.

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

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

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.

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

我相信有很多应用程序可以使用它，但这不是最好的主意。您不能总是指望您的应用程序能够正确地管理数据库，坦白地说，管理数据库不应该是您的应用程序非常关心的问题。

如果您正在使用关系数据库，那么似乎应该在其中定义一些关系。不幸的是，这种态度(您不需要外键)似乎被许多应用程序开发人员所接受，他们宁愿不为数据完整性等愚蠢的事情所困扰(但需要这样做，因为他们的公司没有专门的数据库开发人员)。通常在这些类型的数据库中，你很幸运只有主键;)

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

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

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

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

这会导致不同的问题:

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

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

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

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

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

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

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.

更大的问题是:你会戴着眼罩开车吗?如果你开发一个没有参考约束的系统就是这样。请记住，业务需求会改变，应用程序设计会改变，代码中相应的逻辑假设也会改变，逻辑本身也会被重构，等等。一般来说，数据库中的约束是在当代逻辑假设下放置的，对于特定的逻辑断言和假设集似乎是正确的。

在应用程序的整个生命周期中，引用检查和数据检查约束控制通过应用程序收集的数据，特别是当新需求驱动逻辑应用程序更改时。

从实时事务处理系统的角度来看，外键本身不会“提高性能”，也不会显著“降低性能”。然而，在大容量“批处理”系统中，约束检查存在一个聚合代价。这就是实时和批量事务处理的区别;批处理——通过约束检查，按顺序处理的批处理的总成本会对性能造成影响。

在一个设计良好的系统中，数据一致性检查将在处理批处理之前完成(然而，这里也有相关的成本);因此，加载时不需要外键约束检查。事实上，所有的约束，包括外键，都应该暂时禁用，直到批处理完成。

QUERY性能——如果表是在外键上连接的，那么要认识到外键列不是索引的事实(尽管根据定义，各自的主键是索引的)。通过索引一个外键，也就是索引任何键，在索引上连接表有助于提高性能，而不是通过连接一个带外键约束的非索引键。

Changing subjects, if a database is just supporting website display/rendering content/etc and recording clicks, then a database with full constraints on all tables is over kill for such purposes. Think about it. Most websites don’t even use a database for such. For similar requirements, where data is just being recorded and not referenced per say, use an in-memory database, which does not have constraints. This doesn’t mean that there is no data model, yes logical model, but no physical data model.