SQL:你需要一个多对多表的自增主键吗？

Question

假设您在艺术家和粉丝之间有一张多对多表。在设计 table 时，您是否像这样设计 table :

ArtistFans
    ArtistFanID (PK)
    ArtistID (FK)
    UserID (FK)

 (ArtistID and UserID will then be contrained with a Unique Constraint 
  to prevent duplicate data) 

或者您是否为两个相关领域构建使用复合 PK:

ArtistFans
    ArtistID (PK)
    UserID (PK)

(The need for the separate unique constraint is removed because of the 
 compound PK)

使用以前的模式有什么好处(也许是索引？)？

Answer 1

ArtistFans
    ArtistID (PK)
    UserID (PK)

使用自动增量 PK 在这里没有优势，即使父表有它们。

我还会在 (UserID, ArtistID) 上自动创建一个“反向 PK”索引太:您将需要它，因为您将按两列查询表。

自动编号/ID 列有它们的位置。在基于物理平台的规范化过程之后，您会选择它们来改进某些事情。但不适用于链接表:如果你脑残的 ORM 坚持，那么改变 ORM ......

编辑，2012 年 10 月

重要的是要注意，您仍然需要唯一的 (UserID, ArtistID)和 (ArtistID, UserID)索引。添加自动增量只会使用更多不应使用的空间(在内存中，而不仅仅是在磁盘上)