SQL Server中的多对多关系结构是否有额外的主键列?

你需要一个复合材料 UNIQUE RoleId, ReportId )无论如何。

不做这件事毫无意义 PRIMARY KEY .

CLUSTERED PRIMARY KEY (默认情况下),这将在性能方面更好,因为它的大小更小。

群集主键在每个记录中仅包含两列: RoleID ReportID ,而辅助索引将包含三列: 罗莱德 , 和 RoleReportID (作为行指针)。

您可能需要在上创建一个附加索引 可用于搜索所有 Roles Report .

1. 您的关系中有其他属性(即,此表包含其他列,如 Date 或其他任何东西)
   • 太多了 FOREIGN KEY

在这种情况下,最好只有一列 主键 指 外键

既然你似乎没有这种需要,就做一个复合材料吧 主键 .

其实你不知道 需要

许多人试图避免在实际表中使用自然唯一的键,而是选择人工唯一的键,但我并不总是同意这一点。例如,如果您可以确保您的SSN永远不会更改,则可以使用 作为一把钥匙。如果有什么原因 未来的改变,你可以在那时修复它。

当然

除非你真的需要 RoleReportId 作为其他表中的外键(通常情况下不会是这样),使用选项2。它将需要更少的存储空间,而这本身可能会带来性能优势——另外,为什么会有一个永远不会使用的列呢?

从语义上讲,区别在于您使用什么作为主键。

通常,我会让模式的其余部分决定我在这种情况下的操作。如果交叉表是多对多关系的专用实现,我倾向于使用连接主键。如果我在交叉表上挂起更多的信息,使之成为一个独立的实体,我更倾向于给它自己的id,而不依赖于它所连接的两个表。

当然,这是主观的。我并不认为这是唯一正确的方法(tm)。

如果您有许多行,那么在RoleId和/或ReportId列上具有适当排序的索引可能会很有好处,因为这将加快查找操作,但反过来会减慢插入/删除操作。这是一个典型的使用配置文件问题。。。

如果没有其他要求,请省略 RoleReportId

我建议你第二个选择不要PK。可以对两列的组合使用索引或唯一约束。

当您(或其他人,取决于您公司的结构)需要编写一个针对单个角色的前端时,使用RoleReportID作为单列主键的好处就来了<-&燃气轮机;报告关系(例如,删除关系)。在这一点上,您可能更喜欢只需要寻址一列而不是两列来标识链接记录。

除此之外,您不需要RoleReportID列。