为啥要用多列作为主键（复合主键）

Posted 2023-02-16

【中文标题】为啥要用多列作为主键（复合主键）

【英文标题】：Why use multiple columns as primary keys (composite primary key)为什么要用多列作为主键（复合主键）

【发布时间】：2011-02-07 05:50:14

【问题描述】：

这个例子取自from w3schools。

CREATE TABLE Persons
(
    P_Id int NOT NULL,
    LastName varchar(255) NOT NULL,
    FirstName varchar(255),
    Address varchar(255),
    City varchar(255),
    CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName)
)

我的理解是两列（P_Id 和LastName）一起代表表Persons 的主键。这是正确的吗？

为什么有人要使用多列而不是单列作为主键？ 在给定表中可以将多少列一起用作主键？

【问题讨论】：

...现在还有一个answer for the 2'nd question

@Martijn Peters。为什么答案被删除了？

【参考方案1】：

你的理解是正确的。

在很多情况下你会这样做。一个例子是像OrderHeader 和OrderDetail 这样的关系。 OrderHeader 中的 PK 可能是 OrderNumber。 OrderDetail 中的 PK 可能是 OrderNumber 和 LineNumber。如果是这两者中的任何一个，它就不会是唯一的，但两者的组合保证是唯一的。

替代方法是使用生成的（非智能）主键，例如在本例中为 OrderDetailId。但是你不会总是那么容易地看到这种关系。有些人喜欢一种方式；有些人更喜欢另一种方式。

【讨论】：

如果我使用 branch_id 并使用两个数据库之间的复制，这是否有用，将解决 ids 的重复？！！

请注意，在许多使用生成的主键的情况下，您通常仍需要复合值上的唯一键。

请详细说明“有些人喜欢一种方式；有些人喜欢另一种方式”。

请详细说明？不知道该说些什么。我认识一些人喜欢将多个连接字段作为键，因为更容易直观地理解他们正在查看的内容。我知道其他人更喜欢只为每一行分配一个唯一的键，因为它更容易和更快地输入。你问的是这个吗？

该消息是给@Username的。我忘记指导了。

【参考方案2】：

复合主键的另一个例子是关联表的使用。假设您有一个包含一组人员的人员表和一个包含一组组的组表。现在你想在人和组上创建多对多关系。这意味着每个人都可以属于许多组。以下是使用复合主键的表结构。

Create Table Person(
PersonID int Not Null,
FirstName varchar(50),
LastName varchar(50),
Constraint PK_Person PRIMARY KEY (PersonID))

Create Table Group (
GroupId int Not Null,
GroupName varchar(50),
Constraint PK_Group PRIMARY KEY (GroupId))

Create Table GroupMember (
GroupId int Not Null,
PersonId int Not Null,
CONSTRAINT FK_GroupMember_Group FOREIGN KEY (GroupId) References Group(GroupId),
CONSTRAINT FK_GroupMember_Person FOREIGN KEY (PersonId) References Person(PersonId),
CONSTRAINT PK_GroupMember PRIMARY KEY (GroupId, PersonID))

【讨论】：

很好的解释：我认为 m-to-n 关系（在规范化的方式中）需要属性是关键。

加点福利说明会更好

【参考方案3】：

W3Schools 示例并没有说明何时应该使用复合主键，只是给出了使用与其他键相同的示例表的示例语法。

他们选择的示例可能会通过组合无意义的键 (P_Id) 和自然键 (LastName) 来误导您。这种奇怪的主键选择表明以下行根据架构是有效的，并且是唯一标识学生所必需的。直觉上这是没有意义的。

1234     Jobs
1234     Gates

进一步阅读：The great primary-key debate 或只是谷歌meaningless primary keys 甚至细读这个SO question

FWIW - 我的 2 美分是避免多列主键，并使用单个生成的 id 字段（代理键）作为主键，并在必要时添加额外（唯一）约束。

【讨论】：

1) “伟大的主键辩论”链接特别愚蠢，信息是自私的和虚假的。 2）无法避免使行唯一的列上的索引。带有索引的“代理”ID 始终是附加列和附加索引。相当愚蠢，因为它是多余的。而且更慢。

“伟大的主键辩论”并不愚蠢。对于不是 sql 开发人员或 sql DBA 并且不会将所有时间都花在 sql 上的开发人员来说，这是一个非常有效的问题。即使在纯 sql 中，我也宁愿在加入时将无意义的自动生成的键作为主键，而不是记住传递 n 位数据作为自然键。欢迎您提出自己的观点，但我们希望您不要如此轻视。

【参考方案4】：

只要您想确保多个属性组合的唯一性，您就可以使用复合键（具有多个属性的键）。单个属性键不会达到同样的效果。

【讨论】：

为了保证key的唯一性，你可以依靠两个属性的组合来形成一个逻辑上不能重复的key，比如大数据集中的Person和毕业日期。

【参考方案5】：

是的，它们都构成了主键。特别是在没有surrogate key 的表中，可能需要指定多个属性作为每条记录的唯一标识符（不好的示例：同时具有名字和姓氏的表可能需要将它们组合起来是独一无二的）。

【参考方案6】：

一个键中的多个列通常比代理键的性能更差。我更喜欢有一个代理键，然后是一个多列键上的唯一索引。这样，您可以获得更好的性能并保持所需的唯一性。更好的是，当该键中的一个值发生更改时，您也不必更新 215 个子表中的一百万个子条目。

【讨论】：

1) 性能。不在 SQL 平台中（可能在假装的“sql”和免费软件中）。 2) 偏好无关紧要。为了完整性，表格需要什么是相关的。 3) 带有索引的“代理”ID 始终是 additional 列和 additional 索引。所以在任何平台上都会更慢。重新表现，你自相矛盾。 4) 如果您不知道如何正确更新神话中的“215 个子表中的百万个子条目”，请提出问题。

我不同意“一个键中的多个列通常比代理键的性能更差”的说法。当您考虑关系时，通常需要额外的查询来获取关系的代理键。在这一点上，这是一个完整的额外往返更慢的性能明智。

【参考方案7】：

你的第二个问题

在给定的表中，有多少列可以一起用作主键？

是特定于实现的：它是在实际使用的 DBMS 中定义的。^[1],[2],[3] 您必须检查您使用的数据库系统的技术规范。有些非常详细，有些则不然。在网络上搜索这些限制可能很困难，因为术语会有所不同。 复合主键这个词应该是强制性的；）

如果您找不到明确的信息，请尝试创建一个测试数据库，以确保您可以稳定（且具体）地处理限制违规（这是意料之中的）。请注意获取有关此方面的正确信息：有时会累积限制，您会看到不同数据库布局的不同结果。

---

^[1]sql - Composite primary key limit? - Stack Overflow ^[2]SQL Server - Max columns per primary key ^[3]How many maximum number of columns can be part of Primary Key in a table in Oracle 9i and 10g?

【参考方案8】：

在关系数据库中使用中间表时，在多个表上使用主键会派上用场。

我将使用我曾经制作的数据库作为示例，特别是该表中的三个表。几年前，我为网络漫画创建了一个数据库。一个表称为“comics”——列出所有漫画、它们的标题、图像文件名等。主键是“comicnum”。

第二个表是“字符”——它们的名称和简要描述。主键在“charname”上。

由于每部漫画（除了一些例外）都有多个角色，并且每个角色都出现在多部漫画中，因此在“角色”或“漫画”中放置一列来反映这一点是不切实际的。相反，我创建了一个名为“comicchars”的 third 表，它列出了哪些角色出现在哪些漫画中。由于该表本质上是连接两个表，因此它只需要两列：charname 和comicnum，并且主键在两者上。

【参考方案9】：

我们创建复合主键来保证组成单个记录的列值的唯一性。这是一个约束，有助于防止插入不应重复的数据。

即：如果所有学生 ID 和出生证明号码都唯一分配给一个人。那么最好将一个人的主键设置为学生 ID 和出生证明号码的组合，因为这样可以防止您意外插入两个具有不同学生 ID 和相同出生证明的人。