对于以下情况，应该使用 3-4 个属性中的复合主键还是唯一的人工 ID？

Question

对于一个从数据库和系统开发开始的小型初学者项目，我正在尝试开发一个代表学生和考试管理系统经典案例的系统。这是基于下图：
学生和考试这两个简单的实体不会给我带来任何问题，但我正在努力寻找解决两者之间多对多关系的最佳方法。我意识到我必须为此创建一个附加表，但我不确定是否应该选择 3-4 个属性的复合键或具有唯一 ID 的人工键。我已经对这两种方法进行了一些研究，结果如下：

复合键：

使用此解决方案，想法是通过 MatriculationNumber、ExamID 和 Date 来识别测试结果。在我看来，日期也必须添加到密钥中，因为没有通过的考试可能必须再次参加并在系统中进行管理。因此，MatriculationNumber 和 ExamID 不足以唯一确定两个已完成的考试。但是，我也想出了一个极端的例子：如果考试和补课日期（无论出于何种原因）在同一天举行并且两者的成绩相同，比如 5.0，会发生什么？那么就无法区分这两件事。如果考虑到第三次尝试，整个事情就会变得更加困难。

---

人工身份证：

在这种情况下，将创建一个新的人工 ID，以便唯一确定每个结果。但是，第一个解决方案没有任何隐含的优势，例如，每个考试和学生和标签只允许一个条目。但是，我希望我的解决方案尽可能灵活，而不是让数据库的设计决定我的专业。

---

总的来说，我想从专家那里了解这两种解决方案中的哪一种更适合我的应用。应该可以淘汰一个学生的同一次考试的多次尝试，即使他们可能在同一天落下。我不想让数据库决定或限制主题。还应该可以根据我在复合键的情况下发现相当困难的内容构建 REST-API，至少在我在网上阅读的内容之后。在您看来，这个问题的最佳实践是什么？

---

编辑
为了更好地描述整体情况，一些额外的细节： 对于实现，我想使用 postgreSQL 数据库。因为这只是一个简单的介绍示例，其中没有存储数十亿条记录或需要时间关键的操作，所以重点根本不在性能上。但是，我发现以后能够扩展应用程序和业务逻辑更为重要，例如通过存储文档或其他信息。我不希望某个功能破坏我的数据库或 API 的完整结构。我在这里主要担心的是，如果我想在带有合并密钥的解决方案中获得更多信息，我可能会发生这样的基本变化。另一方面，我仍然缺乏明确的陈述或理由为什么我应该引入人工ID以及它的优点是什么

Answer 1

我建议使用人工密钥ResultID，原因如下：

• 精确定位单个 TestResult 行（或多个行）以执行 SELECT、UPDATE 或 DELETE 会更容易。例如，对于单列 PK，您可以使用WHERE ResultID IN (id1, id2, ...)或ResultID IN (... subquery ...)。IN无法同时对多列 PK 的所有值进行使用。
• 定义与 的新关系会更容易TestResult，无论是否自引用。假设您还需要在 TestResult 表中管理指向先前结果的“重新获取结果”。单列PK，只需添加一列即可PreviousResultId。使用 3 列 PK，您将被设置为创建 3 列关系混乱（IMO）。