为什么sql中的多对多关系表实现外键为主键？

问题描述：

CREATE TABLE Books(
     BookID SMALLINT NOT NULL PRIMARY KEY, 
     BookTitle VARCHAR(60) NOT NULL, 
     Copyright YEAR NOT NULL 
    ) 




CREATE TABLE Authors(
     AuthID SMALLINT NOT NULL PRIMARY KEY, 
     AuthFN VARCHAR(20), 
     AuthMN VARCHAR(20), 
     AuthLN VARCHAR(20) 
    ) 


CREATE TABLE AuthorBook(
     AuthID SMALLINT NOT NULL, 
     BookID SMALLINT NOT NULL, 
     PRIMARY KEY (AuthID, BookID), 
     FOREIGN KEY (AuthID) REFERENCES Authors (AuthID), 
     FOREIGN KEY (BookID) REFERENCES Books (BookID) 
    )

这里结表authorbook 为什么主键（AUTHORID，BOOKID）用于为什么sql中的多对多关系表实现外键为主键？

为什么不能有一个单独的表ID，并使其主键？

你可以这样做。当更广泛的数据类型存在时，比如varchars，缩放比较好的是PK。对于合成的特殊用例，你肯定需要在特殊用例中看到int id（这里是http://stackoverflow.com/a/38340726）。 – Drew

为什么添加一个代理键到什么已经是代理键？除非决议表要成为另一个细节的主人，否则没有理由在表中添加另一个无意义的关键字。作为一个行业，我们对替代品感到疯狂，恕我直言。 –

答

为什么没有一个单独的表ID并使其成为主键？

因为你会那么需要在AuthID，BookID创建唯一索引，以确保(AuthID, BookID)重复的对不插入此表。

有许多索引通常会减慢插入和更新并增加磁盘上数据的大小。通过使用复合主键，该问题被最小化。尽管如此，某些ORM最值得注意的是Django，不支持多列主键。因此，Django的ManyToManyField确实有一个连续的主键和(AuthID, BookID)上的一个不起作用的键 - 正是您询问的替代方法。

请加入[Campaigns]（http://chat.stackoverflow.com/rooms/95290/campaigns）以尝试处理'mysql'文档。 Thx e4c5 – Drew

很乐意做@Drew – e4c5

为什么sql中的多对多关系表实现外键为主键？

相关推荐