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

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

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

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

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

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

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

我可以看到使用外键的一些原因(有人提到，孤立行很烦人)，但我也从不使用它们。对于一个相对正常的DB模式，我不认为它们是100%需要的。约束是好的，但我认为通过软件来实施约束是更好的方法。

亚历克斯

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

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

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

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

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

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

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