ERD 的部分显示了 3 个表之间的关系。
一个用户可以拥有多个目标（歌曲）
一个轨道可以由多个用户拥有
中间的表解决了多对多关系并具有复合主键。以及存储有关特定用户如何评价特定曲目的信息。
中间表是否需要一个新的主键“User_Rating_ID”还是可以（更好？）将其保留为复合键？
问问题
961 次
3 回答
1
交集表定义了两个实体之间的关系。如果这是匿名关系，则不需要单独的代理键。
例如，零件表和单元表可以有一个表，该表定义了用于制造每个单元的零件。每个部分可以用在几个单元中，每个单元由许多部分组成（有时是几个特定部分）。这样的表可能如下所示：
UnitID PartID Qty
这样的交集表可能没有代理键。被问到的关系的常见问题将是：
- 哪些零件用于制造 Unit X？
- 用于制造 X 单元的最便宜/最昂贵的部件是什么？
- 哪些单位包含 P 部分？
- 哪些单位需要最多数量的 P 部分？
我想不出任何情况下甚至会使用这种关系的单独键。所有问题都将涉及特定部分或特定单元。
另一方面，参加课程和学期。交叉表将建立课程，即教授课程的特定课程。同一学期内可能会有多个特定课程的实例。史密斯教授在 mwf 上每天上 1 小时的 Math-101 课，琼斯教授在第 t 天每天上 1.5 小时。
在注册和其他未来记录保存期间，将跟踪的不是Math-101 或学期，而是将使用的特定课程。因此，需要一个单独的代理键。
分析将在您的实例中确定关系是否是匿名的。
于 2017-05-01T03:13:06.780 回答
0
这取决于您如何使用数据。
从严格逻辑的角度来看，复合主键说明了需要说的内容，并且工作得很好。在一些不寻常的情况下，单独的 PK 可能会有所帮助。
于 2017-04-30T16:22:47.670 回答
0
具有由两个外键列组成的复合主键的多对多交集表没有任何问题，这两个外键列指向通过交集链接的两个表。
有些人可能还想在这样的交集表中添加一个额外的候选主键，特别是一个无意义的系统生成的 ID 号（或 GUID 等）。
有人可能这样做的原因包括：*
- “父”（链接）表可能会在一端发生变化，并且由于某种原因更新一个（或多个）外键会很复杂。有些人不喜欢更新主键。一些 ORM 不允许这样做。
- 交集本身可能是一个或多个子表的父表，这些子表需要具有指向交集的外键。将复合键传播到其他表可能会使您的代码复杂化，并且您的 ORM 可能支持也可能不支持（如果您使用的是 ORM）。
- 有时，您有一个基于用户界面的原因来使用单列候选键，例如您的交叉点中的记录显示在组合框中，并且组合框控件具有单个列表项整数数组，可让您从交点表。
- 您可能有某种系统约束，要求您在每个表上都有一个代理键，而不管存在哪些其他候选主键。例如，您可能有一个审计日志记录机制来跟踪诸如
table_name、record_id、change_date、change_user等项目。 - 有些人只是觉得每张桌子都需要一个代理键，因为那是他们的世界观。
* 注意：我不是出于任何这些原因提倡。我是说他们是你会在“野外”发现的观点。您的里程可能会有所不同，请自行决定等。
于 2017-04-30T17:21:19.837 回答