使用复合键作为主键还是有 2 个外键和另一个单独的字段作为主键？答案

【问题标题】：Use a composite key as the primary key or have 2 foreign keys and another seperate field as the primary key?使用复合键作为主键还是有 2 个外键和另一个单独的字段作为主键？
【发布时间】：2014-12-08 11:58:49
【问题描述】：

我有以下表格：

|学生 |

学生证(P)
姓名
...

|招聘 |

JobID(P)
职位名称
...

|应用 |

工作 ID
学生证
应用程序ID
...

我应该去掉 Application 表中的 ApplicationID 并使用 JobID 和 StudentID 作为复合主键，还是应该将它们作为外键并使用 ApplicationID 作为主键？

注意：如果有影响，我将施加限制，例如学生只能接受一份申请，在申请后 3 周内接受等。

谢谢

【问题讨论】：

鉴于 Application 表在某些时候也可以从其他地方引用，我将保留单个 PK ApplicationID。
太棒了，谢谢 - @KouberSaparev 如果你作为答案我会投票作为答案？

标签： sql postgresql foreign-keys primary-key composite-key

【解决方案1】：

从理论的角度来看，ApplicationID 主键在这个阶段可能看起来是多余的（假设只有这 3 个表），因此您可能会想放弃它并切换到更自然的复合主键 @987654322 @。

但是，有两个强有力的实际反驳论据。

您的数据结构可能会超出这 3 个表，并且在某些时候，Application 表本身可能会从其他地方引用。这意味着引用该表的每个外键也应该是复合的，并且由StudentID 和JobID 组合组成，everywhere。
SQL 层之外的每个应用程序都应基于此复合主键映射到Application 表，以便从中查看/编辑或删除条目。

根据您的具体情况，由您决定上述 2 点的强度。如果 Application 表被引用的概率趋于 0，并且您不打算通过上层软件对其进行管理，那么复合主键是可行的方法。在所有其他情况下，我会选择使用单个主键 ApplicationID 并在 (StudentID, JobID) 上设置一个额外的唯一约束。

【讨论】：

还有第三个原因（恕我直言）：将来，应用程序表中可能需要一个额外的键列“start_date”，以允许同一个人获得工作，退出它，并再次被雇用。
确实，这看起来像是一个完全有效的场景，它甚至质疑(StudentID, JobId) 组合的唯一性。
{studentId, JobId, start_date} 会形成一个自然的PK。（但您可能会遇到两个 FK 的 NULLability 问题；无论如何最好将它们定义为 NOT NULL）（和/或可能保留代理以允许将来在 {studentId, JobId, start_date} 中进行“关键”更新）