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

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

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

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

亚历克斯

跨应用程序生命周期的可维护性和稳定性如何?大多数数据的生命周期都比使用它的应用程序长。关系和数据完整性非常重要，不能寄希望于下一个开发团队在应用程序代码中做出正确的处理。如果您没有使用过不尊重自然关系的脏数据的db，那么您将会使用。数据完整性的重要性将变得非常清楚。

对我来说，如果您想要遵循ACID标准，那么拥有外键以确保引用完整性是至关重要的。