代理与自然键：性能差异的硬性数字？

代理键和自然键之间存在着一场健康的争论：

所以帖子 1 https://stackoverflow.com/questions/1207983/in-general-should-every-table-in-a-database-have-an-identity-field-to-use-as-a-p

所以帖子2 https://stackoverflow.com/questions/63090/surrogate-vs-natural-business-keys

我的观点似乎与大多数人（微弱多数）一致，即您应该使用代理键，除非自然键完全明显并且保证不会更改。然后您应该强制自然键的唯一性。这意味着几乎所有时候都需要代理键。

两种方法的示例，从 Company 表开始：

1：代理键：表有一个 ID 字段，它是 PK（和身份）。州要求公司名称是唯一的，因此存在唯一约束。

2：自然键：表使用CompanyName和State作为PK——既满足PK又满足唯一性。

假设 Company PK 用于其他 10 个表。我的假设（没有数字支持）是代理键方法在这里会快得多。

我见过的关于自然键的唯一令人信服的论据是对于使用两个外键作为自然键的多对多表。我认为在这种情况下这是有道理的。但如果您需要重构，您可能会遇到麻烦；我认为这超出了本文的范围。

有谁看过比较的文章性能差异在一组使用的表上代理键 vs.使用同一组表自然键？环顾 SO 和 Google 并没有产生任何有价值的东西，只是大量的理论构建。

重要更新: 我已经开始构建一个一组测试表回答这个问题。它看起来像这样：

• PartNatural - 使用的零件表 作为 PK 的唯一 PartNumber
• PartSurrogate - 零件表 使用ID（int，identity）作为PK并且 PartNumber 上有唯一索引
• 植物 - ID（int，identity）作为 PK
• 工程师-ID(int,identity)作为PK

每个零件都连接到一个工厂，并且工厂中零件的每个实例都连接到一个工程师。如果有人对此测试平台有疑问，现在就是时候了。

两者都用！自然键可以防止数据库损坏（不一致可能是一个更好的词）。当“正确的”自然键（为了消除重复行）由于长度或涉及的列数而表现不佳时，出于性能目的，也可以添加代理键以用作其他表中的外键，而不是自然键...但是自然键应该保留作为备用键或唯一索引，以防止数据损坏并强制数据库一致性...

大部分的欢呼（在关于这个问题的“辩论”中）可能是由于一个错误的假设 - 你必须使用首要的关键用于其他表中的联接和外键。这是错误的。你可以使用任何key作为其他表中外键的目标。它可以是主键、备用键或任何唯一索引或唯一约束，只要它在目标关系（表）中是唯一的。至于连接，你可以使用anything对于连接条件来说，它甚至不必是键、索引，甚至不必是唯一的！ （尽管如果它不是唯一的，您将在它创建的笛卡尔积中获得多行）。您甚至可以使用非特定条件（例如 >、

事实上，您可以使用任何计算结果为布尔值的有效 SQL 表达式来创建联接。