有一个很好的理由不使用它们:如果你不了解它们的作用或如何使用它们。

在错误的情况下，外键约束可能导致事故的瀑布式复制。如果有人删除了错误的记录，恢复它可能会成为一项艰巨的任务。

同样，相反，当您需要删除某些内容时，如果设计不当，约束可能会导致各种锁阻止您的操作。

使用外键的原因:

you won't get Orphaned Rows you can get nice "on delete cascade" behavior, automatically cleaning up tables knowing about the relationships between tables in the database helps the Optimizer plan your queries for most efficient execution, since it is able to get better estimates on join cardinality. FKs give a pretty big hint on what statistics are most important to collect on the database, which in turn leads to better performance they enable all kinds of auto-generated support -- ORMs can generate themselves, visualization tools will be able to create nice schema layouts for you, etc. someone new to the project will get into the flow of things faster since otherwise implicit relationships are explicitly documented

不使用外键的原因:

you are making the DB work extra on every CRUD operation because it has to check FK consistency. This can be a big cost if you have a lot of churn by enforcing relationships, FKs specify an order in which you have to add/delete things, which can lead to refusal by the DB to do what you want. (Granted, in such cases, what you are trying to do is create an Orphaned Row, and that's not usually a good thing). This is especially painful when you are doing large batch updates, and you load up one table before another, with the second table creating consistent state (but should you be doing that sort of thing if there is a possibility that the second load fails and your database is now inconsistent?). sometimes you know beforehand your data is going to be dirty, you accept that, and you want the DB to accept it you are just being lazy :-)

我认为(我不确定!)大多数已建立的数据库都提供了一种指定外键的方法，这种方法不是强制的，只是一些元数据。由于不强制执行消除了不使用fk的所有理由，如果第二部分中的任何理由适用，您可能应该走那条路。

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

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

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

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

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.

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

我同意德米特里的话，但要补充一点。

我在一个批处理计费系统中工作，需要在30多个表中插入大量的行。我们不允许做数据泵(Oracle)，所以我们必须做批量插入。这些表上有外键，但我们已经确保它们不会破坏任何关系。

在插入之前，我们禁用外键约束，这样Oracle就不会一直进行插入。插入成功后，我们重新启用约束。

PS:在一个大型数据库中，一条记录有许多外键和子行数据，有时外键可能不好，您可能希望禁止级联删除。对于在计费系统中的我们来说，如果进行级联删除，将花费太长时间，并且对数据库造成太大负担，因此我们只是在主驱动程序(父)表上使用一个字段将记录标记为坏记录。

我只知道Oracle数据库，不知道其他数据库，而且我知道外键对于保持数据完整性是必不可少的。在插入数据之前，需要建立一个数据结构，并且建立正确的数据结构。当这一步完成时——所有的主键和外键都创建好了——工作就完成了!

意思是:孤立的行?不。这辈子都没见过。除非一个糟糕的程序员忘记了外键，或者他在另一个层次上实现了外键。在Oracle的环境中，这两者都是巨大的错误，会导致数据复制、孤儿数据，从而导致数据损坏。我无法想象一个没有强制FK的数据库。在我看来是一片混乱。这有点像Unix权限系统:假设每个人都是root用户。想想混乱吧。

外键是必不可少的，就像主键一样。这就像是说:如果我们移除主键会怎样?那么，整个混乱将会发生。这是什么。不能将主键或外键的职责移到编程级别，但必须移到数据级别。

缺点呢?是的，当然!因为在插入时，会有更多的检查。但是，如果数据完整性比性能更重要，那么这是显而易见的。Oracle上的性能问题更多地与索引有关，索引包含PK和FK。