我听到的观点是前端应该有这些业务规则。当您一开始就不应该允许任何破坏约束的插入时，外键会“增加不必要的开销”。我同意吗?不，但我一直都是这么听说的。

编辑:我猜他指的是外键约束，而不是外键这个概念。

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

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

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

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

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

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

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

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

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.

更新:我现在总是使用外键。对于反对意见“他们使测试变得复杂”，我的回答是“编写单元测试，这样他们就根本不需要数据库。任何使用该数据库的测试都应该正确地使用它，这包括外键。如果准备工作很痛苦，那就找一种不那么痛苦的方式来做。”

外键使自动化测试复杂化

假设您正在使用外键。您正在编写一个自动测试，该测试表示“当我更新财务帐户时，它应该保存交易记录。”在这个测试中，您只关心两个表:帐户和事务。

但是，accounts对契约有一个外键，契约对客户有一个fk，客户对城市有一个fk，城市对州有一个fk。

现在，数据库将不允许您运行测试，除非在四个与测试无关的表中设置数据。

至少有两种可能的观点:

“这是一件好事:你的测试应该是现实的，这些数据限制将存在于生产中。” “这是一件坏事:你应该能够在不涉及其他部分的情况下对系统的各个部分进行单元测试。您可以为整个系统添加集成测试。”

也可以在运行测试时暂时关闭外键检查。至少MySQL支持这一点。

在我参与的一个项目中，经常存在隐式关系而不是显式关系，这样可以在同一列上连接多个表。

请看下面的表格

地址

AddressId (PK) EntityId EntityType 城市 状态 国家 等。

EntityType的值可能是Employee、Company、Customer, EntityId指的是您感兴趣的表的主键。

我真的不认为这是最好的方法，但它对这个项目有效。