我为多对多实体建立了关系表。
author_id | book_id
我需要添加relation_id吗？我应该能够识别使用两个id。
谢谢
答案 0 :(得分：5)
大多数时候在这样的连接表中只将两者都设置为组合PK就可以了。
答案 1 :(得分：4)
你从不需要代理密钥，因为你总是可以原则上使用其他密钥。
在你的问题中，我不认为你的意思是“关系表”，更不用说“关系”了。我认为你的意思是“一张有多个外键的桌子”。具有多个外键的表与其他表没有区别，它们的设计原则也不必相同。选择与其他表格相同的键。
答案 2 :(得分：3)
我更喜欢在每个表上都有一个列auto-inc键。它使删除和更新变得更加简单。
答案 3 :(得分：3)
您无需添加代理键。我不愿意。
答案 4 :(得分：2)
这里有两个问题。
您需要对书籍/列组合使用唯一约束以防止重复。即使你戴上一个auto-inc代理键，你也必须这样做。
其次，如今许多框架都不知道如何处理除整数键之外的任何内容，因此您可能还想放置整数列。但在这种情况下，你需要两者。
答案 5 :(得分：2)
由于你正在使用Doctrine，所以尽量不要在RDBMS层面上思考太多（至少在大多数情况下都不要这么做）。
如果您有两个具有ManyToMany关系的实体，则应该忘记代理键。实际上，您应该忽略关系表存在的事实。您只需要两个相关的实体类型。
现在，如果您需要存储关于关系本身的元数据（例如，徽章被授予用户的日期），您将超越简单的ManyToMany，并且您需要自己建模这种关系 - 通过创建一种新的实体（例如UserBadge）。当然，那个实体会有一个id。
您正在使用ORM，考虑实体，而不是关于表格（大部分时间）！
答案 6 :(得分：1)
你严格不要需要它，但它在SQL控制台上玩时可能会很方便，特别是如果这两个标识符都很长且很难打字。
另一方面，它打破3NF。如果您不小心，您最终可能会得到两个具有不同代理键和同一对(book_id, author_id)值的记录。你将有两个索引来确保两个唯一性约束;这将减慢插入和更新。
此外，您可能希望避免额外的列以提高效率。如果你的表有很多记录，有一个额外的列将使内存缓存效率降低，并且使用它的连接将更频繁地减慢磁盘I / O.