为什么单个主键比复合键更好？

Question

为什么拒绝复合键有利于使用名为id的单个主键的所有表？因此通常所有ORM都遵循此原则.

编辑

我刚刚开始在轨道上学习ruby,在实用的敏捷开发书中有一条线:--- Rails确实不能很好地工作,除非每个表都有一个数字主键.对列的名称不太挑剔.我在学习Doctrine时读到的那条线.

EDIT2 请检查此链接.我越来越对这件事感到困惑:--- 复合主键与唯一对象ID字段

从以上链接: -

*主键应该是恒定的,毫无意义的; 非代理键通常会失败一个或两个要求,最终

如果密钥不是常量,那么如果密钥没有意义,那么将来的更新问题会变得非常复杂,那么它更有可能发生变化,即不是常数; 往上看

举一个简单的常见例子:库存项目表.将项目编号(SKU编号,条形码,零件代码或其他任何东西)作为主键可能很诱人,但一年后所有项目编号都会发生变化,而且您将面临一个非常混乱的更新 - 整个 - 数据库问题......

编辑:还有一个比哲学更实用的问题.在许多情况下,你会以某种方式找到一个特定的行,然后再更新它或再次找到它(或两者).使用复合键,有更多数据可以跟踪WHERE子句中的更多约束以及重新查找或更新(或删除).在此期间,其中一个关键部分也可能已发生变化!使用代理键,始终只保留一个值(代理ID),根据定义,它不能更改,这可以显着简化情况.*

Answer 1

我不认为你应该只使用一个名为id的主键.

大多数人使用代理主键作为自动生成int,因为它将主键与需要更改的主密钥隔离开来,就像您将PK作为用户名并稍后更改其合法名称一样.您必须更新PK和所有FK列以反映新名称.如果您使用了代理主键,则只需在一个位置更新用户名(因为表连接的是int而不是名称).

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

拥有自动增量int PK有助于成为一个聚簇索引,因为行按此顺序存储,并且无需返回并阻止行插入新行,您总是添加到表的末尾.

Answer 2

我使用复合键遇到的唯一真正限制是使用IN带有子查询的表达式.这是一个问题,因为IN表达式中的子查询必须返回单个列(至少在T-SQL中).

SELECT
    emp.Name,
    emp.UserDomain,
    emp.UserID
FROM
    employee emp
WHERE
    ???? IN (SELECT e.UserDomain, e.UserID FROM ... /* some complex 
                                                       non-correlated subquery 
                                                       or CTE */
            )

当然,总会有解决方法,但有时可能会令人烦恼.

这几乎不是在使用复合键的地方避免复合键的原因.

Answer 3

你可以使用两者.在某些情况下,在实体之间建立关联时,您可以将两个实体键用作复合键.

根据经验,我使用生成的id作为实体,使用复合键作为关系.

Answer 4

好吧，这基本上是关于使JOIN保持简单-较容易理解：

SELECT
   p.ID, p.Name, p.City,
   c.ID, c.Country, c.ISOCode
FROM
   dbo.Parent p
INNER JOIN
   dbo.Child c on c.ParentID = p.ID

要么

SELECT
   p.ID, p.Name, p.City,
   c.ID, c.Country, c.ISOCode
FROM
   dbo.Parent p
INNER JOIN
   dbo.Child c ON c.ParentName = p.Name
     AND c.ParentCity = p.City
     AND c.ParentCountry = p.Country

如果您有复合主键，那么从子表连接到表的任何人都必须“拖动”所有这些列，并且所有这些列也将出现在子表中，并且JOIN语句非常混乱。为JOIN拥有单个（甚至代理）键会更好！

Answer 5

我开发了一个具有 11 列主键的应用程序。每次我想保证更新一行时，一遍又一遍地重新输入列表总是很有趣。这是一个 bug 驱动程序，MS-Access 无法处理 PK 中超过 10 列的问题，等等。

大型复合键是一种设计味道，这意味着表包含异构实体，或者设计者不确定每个实体的独特之处是什么。（就像假设头发颜色、眼睛颜色和体重应该足以唯一地识别一名员工一样——这不是一个好的关键，因为您需要越来越多的列才能使其发挥作用，最终将包括字段这些因素不稳定且变化很大，例如体重，或者对于某些人来说头发颜色或缺乏头发颜色。）