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

Question

假设我们有两个表:角色和报告.并且它们之间存在着多对多的关系.当然,我想到的唯一解决方案是创建一个交叉表,让我们将它命名为RoleReport.我可以看到该表结构的两种方法:

1. Columns: RoleReportId, RoleId, ReportId
   PK: RoleReportId
2. Columns: RoleId, ReportId
   PK: RoleId, ReportId

他们之间是否存在真正的差异(表现还是其他)？

Answer 1

无论如何,你需要UNIQUE在(RoleId, ReportId)上使用复合索引.

没有做到这一点没有意义PRIMARY KEY.

如果你这样做CLUSTERED PRIMARY KEY(这是默认的),这将在性能方面更好,因为它的尺寸会更小.

甲聚集主键将仅包含两列在每个记录中:RoleID和ReportID,而第二索引将包含三列:RoleID,ReportID和RoleReportID(作为行指针).

您可能想要创建一个额外的索引ReportID,可用于搜索Roles给定的所有索引Report.

如果符合以下两个条件,那么为这种关系制定代理关键点会有一些意义:

1. 您的关系中有其他属性(即此表包含其他列,如Date或其他任何内容)
   • 你有很多表引用这种关系的表FOREIGN KEY

在这种情况下PRIMARY KEY,在FOREIGN KEY关系中引用单列会更好.

既然你似乎没有这个需要,那就做一个复合PRIMARY KEY.

Answer 2

您实际上并不需要 RoleReportId.它没有增加任何关系.

许多人试图避免在真实表格中使用自然独特的键,而是选择人工独特的键,但我并不总是同意这一点.例如,如果您可以确定您的SSN永远不会更改,则可以将其用作密钥.如果它在未来以某种方式发生变化,那么您可以修复它.

但我并不打算争论这一点,双方都有很好的论据.但是,在这种情况下,您肯定不需要人工唯一的密钥,因为您的其他字段都是并且将保持唯一.