MS SQL tworzenie relacji wielu do wielu za pomocą tabeli skrzyżowań

Question

Używam programu Microsoft SQL Server Management Studio i podczas tworzenia tabeli skrzyżowań należy utworzyć kolumnę identyfikatora dla tabeli skrzyżowań, jeśli tak, powinienem ją również ustawić klucz podstawowy i kolumna tożsamości? Lub po prostu zachować 2 kolumny dla tabel, do których przyłączam się w relacji wiele do wielu?

Na przykład, jeśli będzie to wiele do wielu tabel:

MOVIE 
Movie_ID 
Name 
etc... 

CATEGORY 
Category_ID 
Name 
etc... 

powinienem stworzyć tabelę Junction

MOVIE_CATEGORY_JUNCTION 
Movie_ID 
Category_ID 
Movie_Category_Junction_ID 

[i czynią Movie_Category_Junction_ID mojego klucza podstawowego i używają go jako kolumna tożsamości]?

Lub:

MOVIE_CATEGORY_JUNCTION 
Movie_ID 
Category_ID 

[i po prostu zostawić go na tym bez klucza podstawowego lub tabeli tożsamości]?

Answer 1

użyłbym drugiej tabeli Junction

MOVIE_CATEGORY_JUNCTION 
Movie_ID 
Category_ID 

Klucz podstawowy byłoby połączenie obu kolumnach. Będziesz mieć również klucz obcy z każdej kolumny do tabeli Movie i Category.

tabela skrzyżowanie będzie wyglądać podobnie do tego:

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

Zobacz SQL Fiddle with Demo.

Użycie tych dwóch pól jako PRIMARY KEY zapobiega dodawaniu duplikatów kombinacji filmów/kategorii do tabeli.

Answer 2

Istnieją różne szkoły myślenia na ten temat. Jedna szkoła preferuje włączenie klucza podstawowego i nazwanie tabeli łączenia o wiele ważniejszej niż tylko dwie połączone tabele. Rozumowanie jest takie, że chociaż tabela może zacząć wyglądać jak zwykła tablica łącząca, może stać się własną tabelą ze znaczącymi danymi.

Przykładem jest wiele-do-wielu między czasopismami i subskrybentami. Naprawdę ten link jest subskrypcją z własnymi atrybutami, takimi jak data wygaśnięcia, status płatności itp.

Jednak czasami wydaje mi się, że tabela łączenia jest tylko tabelą łączenia. Wiele do wielu relacji z kategoriami jest tego dobrym przykładem.

W tym przypadku oddzielny klucz podstawowy 1 pola nie jest konieczny. Mógłbyś mieć przypisany klucz, który nie zaszkodziłby niczemu, i ułatwiłby usuwanie określonych zapisów. Może to być dobre jako ogólna praktyka, więc jeśli tabela później przekształci się w znaczącą tabelę z własnymi znaczącymi danymi (jako subskrypcje), będzie miała już automatycznie przypisany klucz podstawowy.

Możesz umieścić unikalny indeks na obu polach, aby uniknąć duplikatów. Zapobiegnie to nawet duplikatom, jeśli masz osobny klucz automatycznego przypisywania. Możesz użyć obu pól jako klucza podstawowego (który jest również unikalnym indeksem).

Tak więc, jedna szkoła myślenia może trzymać się z kluczami całkowitymi automatycznie przypisanymi kluczami podstawowymi i unika złożonych kluczy podstawowych. Nie jest to jedyny sposób, aby to zrobić, a może nie najlepszy, ale nie doprowadzi cię to źle, do problemu, w którym naprawdę żałujesz.

Ale z czegoś takiego, jak to, co robisz, prawdopodobnie będzie dobrze z tylko dwoma polami. Wciąż zalecałbym albo uczynienie dwóch pól złożonym kluczem podstawowym, albo przynajmniej umieszczenie unikalnego indeksu na dwóch polach.

Answer 3

Poszedłbym z drugim stołem skrzyżowania. Ale uczyń te dwa pola kluczem podstawowym. To ograniczy liczbę duplikatów.