使用外键作为主键的设计注意事项答案

【问题标题】：Design considerations to using Foreign Key as Primary Key使用外键作为主键的设计注意事项
【发布时间】：2014-10-10 16:35:14
【问题描述】：

对于使用一个表的外键作为另一个表的主键是否有任何一般设计考虑（好/坏/中性）？

例如，假设以下表格是电影目录的一部分：

titles
------
 id


episodes
--------
 title_id (PK/FK)

Episodes 显然可以同时使用 id 和 title_id 来完成，其中 id 是 PK，title_id 是 UNIQUE，但是由于 title_id 已经是唯一的，并且从技术上讲，它可以识别剧集，是否有什么需要考虑的？只是拿来当PK？一般来说呢？您对此有何设计考虑？

感谢您的意见！

【问题讨论】：

是否可以有多个具有相同标题的剧集（例如，标题充当系列标题）？有没有至少一集的标题？
不能有多个同名剧集。是的，可以有一个没有剧集的标题。有不同类型的标题。情节类型的标题将具有情节记录。
那么这看起来很合适。您实际上是在实现一种继承形式（参见this post 的“物理表示”部分）。在这种情况下，添加代理键将无益。

标签： mysql design-patterns database-design shared-primary-key

【解决方案1】：

您的问题的答案基本上是对称为“共享主键”的技术的描述。因此，我将关于主键和外键的两个标签替换为单个标签 shared-primary-key。

共享主键是一种设计，其中一个表的 PK 也是引用另一个表的 PK 的 FK。正如 shared-primary-key 的标签 wiki 所示，这对于一对一关系很有用，无论它们是强制性的还是可选的。这些关系有时称为 IS-A 关系，如“汽车就是交通工具”。车辆和汽车之间的关系也称为类/子类或类型/子类关系。

与任何设计技术一样，它有其优点和成本。

编辑回复评论：

共享主键的最大好处是它强制关系的一对一性质。在数据库中强制执行此规则通常比尝试确保所有应用程序代码都遵循规则更有效率。

第二个好处是使两个表之间的连接变得简单而快速。它很快（对于某些数据库系统），因为优化器使用为支持 PK 而构建的索引来加速连接。

第三个好处是第三个表可以使用相同的 FK 引用这两个表。

成本是在向两个表中添加新条目时涉及一些编程。必须将主表中的 PK 复制到辅助表中，系统通常不会为您执行此操作。此外，加入虽然很快，但不是免费的。

【讨论】：

嗯，当然......这就是我要问的。有哪些好处和成本？（感谢您将我指向 shard-primary-key 标记。）