MS SQL che crea relazioni molti-a-molti con una tabella di giunzione

Question

Utilizzo Microsoft SQL Server Management Studio e durante la creazione di una tabella di giunzione dovrei creare una colonna ID per la tabella di giunzione, in caso affermativo dovrei anche renderla chiave primaria e colonna identità? O mantieni solo 2 colonne per le tabelle che sto unendo alla relazione many-to-many?

Per esempio, se questo sarebbe il tipo molti a molti tavoli:

MOVIE 
Movie_ID 
Name 
etc... 

CATEGORY 
Category_ID 
Name 
etc... 

Devo fare la tabella di collegamento:

MOVIE_CATEGORY_JUNCTION 
Movie_ID 
Category_ID 
Movie_Category_Junction_ID 

[e rendere il Movie_Category_Junction_ID mia chiave primaria e usarlo come la colonna Identity]?

Oppure:

MOVIE_CATEGORY_JUNCTION 
Movie_ID 
Category_ID 

[e lasciare solo le cose come stanno, senza chiave primaria o un tavolo identità]?

Answer 1

Vorrei utilizzare la seconda tabella di collegamento:

MOVIE_CATEGORY_JUNCTION 
Movie_ID 
Category_ID 

La chiave primaria sarebbe la combinazione di entrambe le colonne. Avresti anche una chiave esterna da ogni colonna alla tabella Movie e Category.

La tabella di giunzione sarebbe simile a questa:

create table movie_category_junction 
(
    movie_id int, 
    category_id int, 
    CONSTRAINT movie_cat_pk PRIMARY KEY (movie_id, category_id), 
    CONSTRAINT FK_movie 
     FOREIGN KEY (movie_id) REFERENCES movie (movie_id), 
    CONSTRAINT FK_category 
     FOREIGN KEY (category_id) REFERENCES category (category_id) 
); 

Vedi SQL Fiddle with Demo.

L'utilizzo di questi due campi come PRIMARY KEY impedirà l'aggiunta di duplicati di combinazioni di film/categorie alla tabella.

Answer 2

Ci sono diverse scuole di pensiero su questo. Una scuola preferisce includere una chiave primaria e nominare la tabella di collegamento qualcosa di più significativo delle sole due tabelle che collega. Il ragionamento è che sebbene la tabella possa apparire come un semplice tavolo di collegamento, potrebbe diventare una tabella con dati significativi.

Un esempio è un numero molti-a-molti tra riviste e abbonati. In realtà quel collegamento è un abbonamento con i propri attributi, come data di scadenza, stato di pagamento, ecc.

Tuttavia, a volte penso che una tabella di collegamento sia solo una tabella di collegamento. Il rapporto molti a molti con le categorie è un buon esempio di questo.

Quindi, in questo caso, non è necessaria una chiave primaria di campo separata. Potresti avere una chiave di assegnazione automatica, che non danneggerebbe nulla, e renderebbe più facile l'eliminazione di record specifici. Potrebbe essere una buona pratica, quindi se la tabella successivamente si sviluppa in una tabella significativa con i propri dati significativi (come sottoscrizioni), avrà già una chiave primaria di assegnazione automatica.

È possibile inserire un indice univoco sui due campi per evitare duplicati. Ciò impedirà anche i duplicati se hai una chiave di autoassegnazione separata. È possibile utilizzare entrambi i campi come chiave primaria (che è anche un indice univoco).

Così, la sola scuola di pensiero può attaccare con l'intero autoassegnare le chiavi primarie ed evitare le chiavi primarie composte. Questo non è l'unico modo per farlo, e forse non il migliore, ma non ti porterà in errore, in un problema in cui ti dispiace davvero.

Ma, per qualcosa di simile a quello che stai facendo, probabilmente starai bene solo con i due campi. Consiglio comunque di rendere i due campi una chiave primaria composta o almeno di inserire un indice univoco sui due campi.

Answer 3

Vorrei andare con il 2 ° tavolo di congiunzione. Ma rendi questi due campi come chiave primaria. Ciò limiterà le voci duplicate.