sql - 复合主键与附加 "ID"列？

Question

如果我们有这样一张表:

书籍(假装“ISBN”不存在)

• 作者
• 职位
• 版本
• 出版年份
• 价格

有人可能会争辩说 {Author,Title,Edition} 可能是候选/主键。

是什么决定了候选/主键是否应该是 {Author,Title,Edition} 或者是否应该使用 ID 列，{Author,Title,Edition} 是一个唯一的索引/键约束？

也是

• 作者(PK)
• 标题(PK)
• 版本(PK)
• 出版年份
• 价格

更好，或者:

• 身份证(PK)
• 作者
• 职位
• 版本
• 出版年份
• 价格

其中 {Author,Title,Edition} 是一个额外的唯一索引/约束？

Answer 1

假设 {Author, Title, Edition} 唯一标识一本书，则以下成立:

1. 它是一个 super 键——唯一标识一个元组(行)。

2. 它是不可约的——删除任何列都不会使其成为键。

3. 它是一个候选键——不可约的 super 键是一个候选键。

现在让我们考虑 ID(整数)

我可以推断 Book 表键将作为外键出现在少数其他表中，也出现在少数索引中。因此，这将占用相当大的空间——比如三列 x 40 个字符(或其他……)——在每个表中加上匹配的索引。

为了使这些“其他”表和索引更小，我可以将一个唯一整数列添加到 Book 表中用作将被引用为外键的键.像这样说:

alter table Book add BookID integer not null identity;

BookID 也(必须)是唯一的，Book 表现在有两个候选键。

现在我可以选择 BookID 作为主键。

alter table Book add constraint pk_Book primary key (BookID);

但是，{Author,Title,Edition} 必须保持一个键(唯一)以防止这样的事情:

BookID  Author      Title           Edition
-----------------------------------------------
  1      C.J.Date  Database Design     1
  2      C.J.Date  Database Design     1

总而言之，添加 BookID——并选择它作为主要——并没有阻止 {Author, Title, Edition} 成为(候选) key 。它仍然必须有自己的唯一约束，通常还有匹配索引。

还要注意，从设计的角度来看，这个决定是在“物理层面”上做出的。通常，在设计的逻辑层面上，这个 ID 是不存在的——它是在考虑列大小和索引时引入的。因此，物理模式是从逻辑模式中派生出来的。根据 DB 大小、RDBMS 和使用的硬件，这些大小推理可能都不会产生可衡量的效果——因此使用 {Author, Title, Edition} 作为 PK 可能是完美的设计——直到证明不同。