自己的唯一约束还是作为主键？

Question

使用这样的表架构有什么好处：

CREATE TABLE review (
    review_id SERIAL PRIMARY KEY,
    account_id INT REFERENCES account(account_id) NOT NULL, 
    product_id INT REFERENCES product(product_id) NOT NULL, 
    rating SMALLINT NOT NULL, 
    comment TEXT,
    UNIQUE (account_id, product_id)
);

或者约束本身应该是主键，像这样：

CREATE TABLE review (
    CONSTRAINT review_pkey (account_id, product_id) PRIMARY KEY,
    account_id INT REFERENCES account(account_id) NOT NULL, 
    product_id INT REFERENCES product(product_id) NOT NULL, 
    rating SMALLINT NOT NULL, 
    comment TEXT,
);

Answer 1

第二个版本显然更可取，因为它需要少一列和少一索引，而且没有缺点。

列很明显，索引不是，因为您忘记添加它们： 您需要所有外键列的索引，以便可以快速删除引用的表。使用人工主键，您需要review_id、account_id 和product_id 上的索引，而没有您可以使用(account_id, product_id) 和product_id 上的索引。

唯一支持第一个解决方案的人是那些坚信每张表都必须有一个人工生成的数字主键的人，无论如何。实际上，从引用的表中人工生成的两个键的组合也一样好。

Answer 2

除了宗教、习惯、个人偏好和某些客户端工具的便利性之外，还有其他很好的理由需要额外的代理 PK，如您的第一个示例所示。

如果您要使用其他表中的外键引用该表：

• 引用表只需要包含单个代理 PK 列作为 FK 引用，这样更小、更快、更简单。如果引用表有很多行而review 没有，则单个实例可能已经超过了review 的额外成本。否则，可能会有多个实例。
  对于在 许多 行中引用的小型查找表，甚至可以考虑使用 smallserial 代理 PK - 如果 实际上 有帮助的话。见：

  • Calculating and saving space in PostgreSQL

• 通常，在引用表的 FK 列上也会有一个索引。您的带有两个 integer 的示例最适合多列 PK / FK，因为它将索引大小保持在最低限度。两个integer 列上的B 树索引不大于单个integer 上的一个（8 字节通常是索引元组的最小“有效负载”）。其他更大的数据类型会产生额外的影响。

• 如果review 收到对(account_id, product_id) 列之一的许多更新，则这些更新将级联到基于这两列的所有引用表。成倍增加写入成本，使多个表和索引膨胀。如果它级联到宽行或许多引用行，则成本可能会大幅增加。所有这些都可以通过代理 PK 来避免 - 如果关系设计实际上应该以这种方式工作。

如果review 涉及到许多使用连接的查询，连接两列而不是一列会更繁琐且成本略高。同样，对于更大的数据类型更是如此。

也就是说，如果您没有上述（或类似），请查看 Laurenz 的回答。

权衡实际成本，而不是宗教信仰。