database-design - 为什么单主键比复合键好？

Question

为什么拒绝复合键而支持使用名为 id 的单个主键的所有表？因为一般所有的 ORM 都遵循这个。

编辑

我刚开始在 Rails 上学习 ruby​​，在敏捷开发的书中有一条线:---
除非每个表都有一个数字主键，否则 Rails 真的不能很好地工作。对列的名称不那么挑剔。
我在学习 Doctrine 时读过的同样的台词。

编辑2
也请检查此链接。我对这件事越来越困惑:---
Composite primary keys versus unique object ID field

从上面的链接:--

*主键应该是常量和无意义的；非代理键通常无法满足一项或两项要求，最终

如果 key 不是恒定的，您将遇到一个可能会变得非常复杂的 future 更新问题
如果 key 不是无意义的，那么它更有可能改变，即不是恒定的；看上面

举一个简单、常见的例子:一个库存项目表。将商品编号(SKU 编号、条形码、零件代码或其他任何内容)设为主键可能很诱人，但一年后所有商品编号都发生了变化，您将面临非常困惑的整体更新——数据库问题...

编辑:还有一个比哲学更实用的问题。在许多情况下，您会以某种方式找到特定行，然后更新它或再次找到它(或两者兼而有之)。使用复合键，有更多的数据需要跟踪，并且在 WHERE 子句中有更多的约束来重新查找或更新(或删除)。也有可能其中一个关键段可能在此期间发生了变化!。使用代理键时，始终只保留一个值(代理 ID)，并且根据定义，它不能更改，这大大简化了情况。*

Answer 1

我不认为有一个笼统的声明，你应该只使用一个名为 id 的主键。

大多数人使用代理主键作为自动生成 int，因为它隔离了主键不需要更改，就像如果您将 PK 设为用户名，然后他们更改了他们的合法名称。您必须更新 PK 和所有 FK 列以反射(reflect)新名称。如果您使用了代理主键，则只需在一处更新用户名(因为表连接到 int 而不是名称)。

主键的大小很重要，因为 PK 会复制到您在表上构建的每个索引中。如果 PK 很大(如字符串)，则索引中每页的键较少，索引将占用更多缓存内存来存储它。整数很小。

拥有一个自动增量 int PK 可以很好地成为一个聚集索引，因为行是按这个顺序存储的，并且不需要返回并颠倒行来插入新行，你总是添加到表的末尾.