SQL-many-to-many 表主键

这个问题出现在阅读了这个问题的评论之后:

数据库设计

当您创建一个多对多表时，您是应该在两个外键列上创建一个复合主键，还是创建一个自动递增的代理“ ID”主键，然后只在两个 FK 列上添加索引(可能还有一个惟一的约束) ？在每种情况下插入新记录/重新索引对性能有什么影响？

基本上是这样:

PartDevice
----------
PartID (PK/FK)
DeviceID (PK/FK)

与此相反:

PartDevice
----------
ID (PK/auto-increment)
PartID (FK)
DeviceID (FK)

评论者说:

使得这两个 ID 的 PK 意味着 表在磁盘上进行物理排序 所以如果我们插入 (第1部份/装置1)、(第1部份/装置2)、, (第2部分/第3装置) ，然后(第1部分/第3装置) 数据库将不得不破坏 把最后一张桌子分开插入 在第二条和第三条之间。对于许多人来说 记录，这变得非常成问题 因为它涉及到数百人的洗牌, 成千上万的唱片 相比之下, 自动递增的 PK 允许新的 记录要附加到最后。

我问这个问题的原因是因为我一直倾向于在没有代理自动增量列的情况下执行复合主键，但是我不确定代理键是否实际上性能更好。

65616 次浏览
小开

链接表不需要代理项。

您需要的只是(col1，col2)上的一个 PK 和(col2，col1)上的另一个惟一索引

除非你使用一个 ORM，不能应付和规定您的数据库设计为您..。

编辑: 我在这里回答同样的问题: SQL: 您是否需要一个用于多表的自动增量主键？

小开
最佳答案

对于一个简单的两列多对多映射，我认为使用代理键没有什么实际的好处。在 (col1,col2)上有一个主键保证是唯一的(假设引用表中的 col1和 col2值是唯一的) ，在 (col2,col1)上有一个单独的索引将捕捉那些相反顺序执行得更快的情况。代孕妈妈是在浪费空间。

您不需要单个列上的索引，因为表应该只用于将两个引用的表连接在一起。

在我看来，你在问题中提到的评论不值得它使用的电子。这听起来像是作者认为表存储在一个数组中，而不是一个极高性能平衡的多向树结构。

首先，从来不需要存储或获取 桌子排序，只需要索引即可。而且索引不会是 储存顺序，它将以一种有效的方式存储，以便能够快速检索。

此外，绝大多数数据库表读取 很远的频率高于写入的频率。这使得您在选择端所做的任何事情都比在插入端所做的任何事情更加相关。

小开

我能够回答您的问题的最简短和最直接的方法是说，如果您链接的两个表没有顺序的主键，那么将会对性能产生影响。如前所述，如果链接表没有自己的顺序主键，那么链接表的索引要么变得支离破碎，要么 DBMS 将更加努力地插入记录。这就是大多数人在链接表上放置一个依次递增的主键的原因。

小开

如果引用表，则可能需要增量主键。可能需要使用增量主键从另一个表中提取多对多表中的细节。

比如说

PartDevice
----------
ID (PK/auto-increment)
PartID (FK)
DeviceID (FK)
Other Details

使用 PartDevice.ID 作为 FK 很容易获取“其他详细信息”。因此需要使用增量主键。

小开

因此，似乎如果唯一的工作是链接两个表，最好的 PK 将是双列 PK。

但是，如果它服务于其他目的，然后添加另一个 NDX 作为一个外键和第二个唯一索引的 PK。

索引或 PK 是确保没有重复的最好方法。PK 让 MicrosoftManagementStudio 这样的工具为您完成一些工作(创建视图)


提交答案