Warum implementiert Junction-Tabelle von vielen zu vielen Relation in SQL sowohl Fremdschlüssel als Primärschlüssel?

Question

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) 
    ) 

hier Verknüpfungstabelle ist authorbook warum Primärschlüssel (authorid, BOOKID) verwendet wird

warum nicht eine separate Tabelle ID haben und es Primärschlüssel machen?

Answer 1

Warum nicht eine separate Tabellen-ID haben und sie zum Primärschlüssel machen?

Weil Sie würden dann einen eindeutigen Index für AuthID erstellen müssen, BookID dass doppelte Paare von (AuthID, BookID), um sicherzustellen, werden nicht in diese Tabelle eingefügt.

Viele Indizes verlangsamen normalerweise Einfügungen und Aktualisierungen und erhöhen die Größe der Daten auf der Festplatte. Mit einem zusammengesetzten Primärschlüssel wird dieses Problem minimiert.

Mit dem gesagt, dass bestimmte ORMs am bemerkenswertesten Django, Multi-Colum Primärschlüssel nicht unterstützt. Daher hat Djangos ManyToManyField tatsächlich einen sequentiellen Primärschlüssel zusammen mit einem unque Schlüssel auf (AuthID, BookID) - genau die alternative Methode, nach der Sie gefragt haben.