连接两个表的表是否应该有自己的 ID？答案

【问题标题】：Should a table connecting two tables have its own ID?连接两个表的表是否应该有自己的 ID？
【发布时间】：2011-09-26 14:04:30
【问题描述】：

我有两张桌子：

First
------
id
name

Second
------
id
name

还有一个连接前两个的表：

Third
------
first_id
second_id

第三个表仅用于解决 M:N 问题。它应该有自己的ID吗？

【问题讨论】：

这只是一个风格问题，即你有多喜欢代理键？在每张桌子上放一个；除了关系/连接/连接/链接/other_name_here 表之外的每个表都放一个；仅在我不想找到现有/滚动我自己的密钥的地方使用；仅在有充分理由的情况下使用；会做任何事情来避免代理键；等等
嗯，我的风格是：不需要的东西就不要使用。

标签： sql

【解决方案1】：

如果表只包含两个外键，则没有理由有额外的键。您不会在任何查询中使用它。

当您使用连接表连接表时，您一次连接一个外键，而不是同时连接两个外键，因此连接表中的另一个键没有用处。示例：

select t1.name, t2.name
from First t1
inner join Third t3 on t3.first_id = t1.id -- one foreign key
inner join Second t2 on t2.id = t3.second_id -- the other foreign key

只需将两个外键组合成一个主键即可。

 PRIMARY KEY (first_id, second_id)

【讨论】：

我稍微编辑了你的答案，所以现在答案是完整的。谢谢！
如果我想将第四个表链接到第一个和第二个表怎么办？在这种情况下，我可以在我的第四张表中使用第三张表的id（代表第一张和第二张表，即关系表的id）吗？
@Rao：是的，你可以，但在这种情况下，在第三个表中添加一个额外的键可能更方便。
@Guffa 在我的情况下：stackoverflow.com/q/33277220/1161412 我认为额外的密钥是不可行的，你能看一下吗？

【解决方案2】：

我开始使用两列中的复合 PK，它对我有用了一段时间。

随着业务的增长和业务规则的变化，其中一些表开始获得额外的属性或参与关系，然后我要么需要添加单列 PK，要么只携带一个双键（这会很快变老）。

然后我决定标准化我自己的设计。现在，作为我设计的一部分，我为所有连接表使用了一个额外的单列 PK。

【讨论】：

我认为你是对的；以我的经验，链接表通常可以独立成为一个实体。但严格来说，不需要额外的 Id。

【解决方案3】：

如果它只是一个简单的映射表，那么我会拒绝。那个额外的 ID 有什么用？只需将主键设为复合：(first_id, second_id)。

话虽如此，但我已经看到了可以有一个单独的 ID 的情况，因为使用某些 ORM 工具更容易。但一般来说，如果可以的话，我会说你应该避免使用额外的 ID 列。

【讨论】：

【解决方案4】：

不，您通常不需要在表格上使用 id 字段来连接两者。您可以为连接表设置主键（first_id，second_id）。

【讨论】：

如果我的第四张桌子需要链接到第一张和第二张桌子怎么办？那么在关系表中有一个 ID 列是否有意义？我可以使用这个关系 ID 在我的第四张表和第一张和第二张表之间建立链接吗？

【解决方案5】：

这取决于表“'第三”（连接或连接表）的角色。例如，假设该表表示其他两个表之间的关系。既然都是这样，就不需要额外的Id了。

但是，如果表“一”和“二”之间的这种关系是暂时的，该怎么办？我的意思是，这种关系是有一段时间的。例如所有权、婚姻等。然后您不能将另一个记录/实体添加到连接表（“第三”），因为这样的关系已经存在。

因此，为每个表建立自己的 Id 会更安全。除非我们确定，将来不会发生临时（因为多次）关系。

========================================== 对不起我的英语

【讨论】：