Question

ERD的一部分显示了3个表之间的关系。

用户可以拥有多个tarcks（歌曲）

许多用户可以拥有一个跟踪

中间的表解析了多对多关系并具有复合主键。以及存储特定用户如何评价特定曲目的信息。

中间表是否需要新的主键“User_Rating_ID”，还是可以（更好？）将其保留为复合键？

Answer 1

交集表定义了两个实体之间的关系。如果这是匿名关系，则不需要单独的代理键。

例如，零件表和单位表可以有一个表格，用于定义用于制作每个单元的零件。每个部件可以用在多个单元中，每个单元由许多部件组成（有时是几个特定部件）。这样的表可能如下所示：

UnitID  PartID  Qty

这样的交叉表可能没有代理键。被问及这种关系的常见问题是：

我无法想到甚至会使用这种关系的单独密钥的任何情况。所有问题都涉及特定部分或特定单位。

另一方面，参加一门课程和一个学期。交叉表将建立课程，即教授课程的特定课程。这里可能存在同一学期内特定课程的几个实例。史密斯教授每天可以在m-w-f上进行1小时的Math-101课程，在琼斯教授的每天第1小时进行1.5小时。

在注册和其他未来的记录保存期间，不将是Math-101或将被跟踪的学期，但特定的类将被使用。因此，需要单独的代理密钥。

分析将在您的实例中确定关系是否是匿名的。

Answer 2

这取决于您使用数据的方式。

从严格的逻辑角度来看，复合主键表示需要说什么，并且工作得很好。有一些不寻常的情况，单独的PK可能会有所帮助。

Answer 3

多对多交集表没有任何问题，它具有由两个外键列组成的复合主键，这两个外键列指向通过交叉点链接的两个表。

有些人可能希望向这样的交集表添加额外的候选主键，特别是无意义的系统生成的ID号（或GUID等）。

有人可能会这样做的原因包括：*

“父”（链接）表可能在一端改变，并且由于某种原因更新一个（或多个）外键会很复杂。有些人不喜欢更新主键。有些ORM不允许它。
交集本身可以是一个或多个子表的父级，这些子表需要具有指向交集的外键。将复合密钥传播到其他表可能会使代码复杂化，如果您使用ORM，ORM可能支持也可能不支持。
有时你有一个基于用户界面的原因，有一个列候选键，就像你的交集中的记录显示在一个组合框中，而组合框控件有一个列表项整数数组，可以让你识别从交叉路口表记录。
您可能有某种系统约束要求您在每个表上都有一个代理键，而不管其他候选主键是什么。例如，您可能拥有审核日志记录机制，可以跟踪table_name，record_id，change_date，change_user等项目。
有些人觉得每张桌子都需要有一个代理键，因为这是他们的世界观。

*注意：我不是因为上述任何原因而提倡的。我说他们是“你会在野外”发现的意见。您的里程可能会有所不同，做出自己的决定等等。