From my experience its always better to avoid using FKs in Database Critical Applications. I would not disagree with guys here who say FKs is a good practice but its not practical where the database is huge and has huge CRUD operations/sec. I can share without naming ... one of the biggest investment bank of doesn't have a single FK in databases. These constrains are handled by programmers while creating applications involving DB. The basic reason is when ever a new CRUD is done it has to effect multiple tables and verify for each inserts/updates, though this won't be a big issue for queries affecting single rows but it does create a huge latency when you deal with batch processing which any big bank has to do as daily tasks.

最好避免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)

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

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

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

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

我还认为外键在大多数数据库中是必要的。唯一的缺点(除了强制一致性带来的性能损失之外)是使用外键允许人们编写假定存在功能外键的代码。这绝不应该被允许。

例如，我看到有人编写了一些代码，将插入插入引用表中，然后尝试将插入插入引用表中，而不验证第一次插入是否成功。如果稍后删除外键，则会导致数据库不一致。

您也不能在更新或删除时假设特定的行为。无论是否存在外键，您仍然需要编写代码来执行您想要的操作。如果您假设删除是级联的，但实际上它们不是级联的，那么您的删除将失败。如果您假定对引用列的更新被传播到引用行，但实际上没有，那么您的更新将失败。出于编写代码的目的，最好不要使用这些特性。

如果打开了这些特性，那么您的代码无论如何都会模仿它们，并且会损失一些性能。

所以，总结....如果需要一致的数据库，外键是必不可少的。在您编写的代码中，永远不应假定外键存在或起作用。

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

在DB2中，如果使用mqt(物化查询表)，优化器需要外键约束才能为任何给定的查询选择正确的计划。由于元数据包含基数信息，优化器会大量使用元数据来决定是否使用MQT。