我的数据库中有以下表，它们具有多对多关系，由一个连接表表示，该连接表具有到每个主表的主键的外键：
假设每个 User-Widget 组合都是唯一的。我可以看到关于如何构造定义数据关系的连接表的两个选项：
选项 1 有一个主键列。但是，这似乎没有必要，因为表中存储的唯一数据是两个主表之间的关系，而这种关系本身可以形成唯一键。因此导致选项 2，它具有两列主键，但丢失了选项 1 具有的一列唯一标识符。我还可以选择在第一个表中添加一个两列唯一索引（WidgetID、UserID）。
两者在性能方面是否有任何真正的区别，或者有任何理由更喜欢一种方法而不是另一种方法来构建 UserWidgets 多对多表？
在任何一种情况下，您都只有一个主键。第二个是所谓的复合键。引入新专栏没有充分的理由。实际上，您必须在所有候选键上保留唯一索引。添加新列只会给您带来维护开销。
选择选项 2。
就个人而言，出于以下原因，我会在多对多表中使用合成/代理键列：
合成键不是自然/复合键的替代品，也不PRIMARY KEY是因为它是表中的第一列而成为该表的，所以我部分同意 Josh Berkus 的文章。但是，我不同意自然键总是很好的候选者PRIMARY KEY's，如果它们要用作其他表中的外键，当然也不应该使用它们。
选项 2 使用简单的复合键，选项 1 使用代理键。选项 2 在大多数情况下是首选的，并且接近关系模型，因为它是一个很好的候选键。
在某些情况下，您可能想要使用代理键（选项 1）
根据经验，在对数据进行建模时，您会发现大多数关联实体（多对多）都是事件的结果。人员就业，物品被添加到购物篮等。大多数事件对事件有时间依赖性，其中日期或时间是相关的 - 在这种情况下，代理键可能是最佳选择。
因此，请选择选项 2，但请确保您拥有完整的模型。
我同意前面的答案，但我有一点要补充。如果要向关系添加更多信息并允许相同的两个实体之间存在更多关系，则需要选项一。
例如，如果您想跟踪用户 1 在 userwidget 表中使用小部件 664 的所有时间，则 userid 和 widgetid 不再是唯一的。
在这种情况下，主键有什么好处？考虑无主键的选项：UserWidgets3: WidgetID (FK), UserID (FK)
如果您想要唯一性，请使用复合键 (UserWidgets2) 或唯一性约束。
拥有主键通常的性能优势是您经常通过主键查询表，这很快。在多对多表的情况下，您通常不会按主键查询，因此没有性能优势。多对多表是通过外键查询的，所以应该考虑在WidgetID和UserID上添加索引。
选项 2 是正确答案，除非您有充分的理由添加代理数字键（您已在选项 1 中完成）。
代理数字键列不是“主键”。主键在技术上是唯一标识表中记录的列组合之一。
任何构建数据库的人都应该阅读 Josh Berkus 撰写的这篇文章http://it.toolbox.com/blogs/database-soup/primary-keyvil-part-i-7327，以了解代理数字键列和主键之间的区别。
根据我的经验，向表中添加代理数字键的唯一真正原因是，如果您的主键是复合键并且需要在另一个表中用作外键引用。只有这样，您才应该考虑在表格中添加一个额外的列。
每当我看到每个表都有一个“id”列的数据库结构时，很可能它是由不了解关系模型的人设计的，并且总是会显示 Josh 文章中确定的一个或多个问题。
我会和两者一起去。
听我说：
就反映数据的含义而言，复合键显然是一种不错的正确方法。没有问题。
但是：除非您使用单个生成的主键 - 代理键，否则我在使休眠正常工作时遇到了各种麻烦。
所以我会使用逻辑和物理数据模型。逻辑的有复合键。实现逻辑模型的物理模型具有代理键和外键。
由于每个 User-Widget 组合都是唯一的，因此您应该通过使组合唯一来在表中表示它。换句话说，选择选项 2。否则，您可能有两个条目具有相同的小部件和用户 ID，但用户小部件 ID 不同。
不需要第一个表中的 userwidgetid，就像你说的唯一性来自 widgetid 和 userid 的组合。
我会使用第二个表，保留外键并在 widgetid 和 userid 上添加唯一索引。
所以：
userwidgets(widgetid(fk), userid(fk),
唯一索引（小部件 ID，用户 ID）
)
没有额外的主键有一些性能增益，因为数据库不需要计算键的索引。在上面的模型中虽然这个索引（通过unique_index）仍然是计算出来的，但是我相信这个比较容易理解。