SQL:主键列。人工 "Id"列与 "Natural"列

Question

这个问题已经在这里有了答案:




已关闭10年。

Possible Duplicate:
Relational database design question - Surrogate-key or Natural-key?

当我创建关系表时，会倾向于选择主键列，该列的值是唯一的。但是出于优化和统一的目的，我每次都会创建人工ID列。如果有一列(或多个列组合)应该是唯一的，我会为此创建唯一索引，而不是将它们标记为(复合)主键列。

始终首选人工“Id”列+索引而不是自然列作为主键真的是一个好习惯吗？

Answer 1

这是一场宗教辩论。我个人的喜好是拥有合成主键而不是自然主键，但是双方都有很好的论据。实际上，只要您是一贯且合理的，则任何一种方法都可以正常工作。

如果您使用自然键，则两个主要缺点是复合键的存在和主键值的变异。如果您有复合主键，则显然每个子表中都必须有多个列。当实体之间存在许多关系时，从数据模型的角度来看这可能很麻烦。但这也会给开发查询的人们带来痛苦-创建使用N-1个N-1连接条件并获得几乎正确结果的查询非常容易。如果您具有自然键，那么您还将不可避免地遇到自然键值发生变化的情况，然后您必须通过许多不同的实体来波动这种变化，这比更改表中的唯一值要复杂得多。

另一方面，如果使用合成键，则会浪费空间，方法是添加额外的列，增加额外的开销来维护额外的索引，并且增加了获得功能重复的结果的风险。要么很容易忘记在业务 key 上创建一个唯一约束，要么看到组合上存在一个非唯一索引，而仅仅假定它是一个唯一索引，这是非常容易的。实际上，我几天前就因这种特殊的失败而被咬住了-我已经为复合自然键建立了索引(具有非唯一索引)，而不是创建了唯一约束。愚蠢的错误，但这是相对容易犯的错误。

从查询编写和命名约定的角度来看，我也倾向于使用合成键，因为很高兴知道当您连接表时，A的主键将是A_ID，而B的主键将是B_ID。 。与试图记住A的主键是A_NAME和A_REVISION_NUMBER的组合，而B的主键是B_CODE相比，这要更加自我记录。