Nel caso in molti a molti tavoli hanno una chiave primaria?

Question

Se ho due oggetti che hanno una relazione molti-a-molti, vorrei in genere li modello nel mio schema di database con una tabella molti-a-molti di mettere in relazione le due cose. Ma dovrebbe che molti-a-molti tabella (o "join table") hanno una chiave primaria della propria (intero auto-incrementato)?

Per esempio, potrei avere tabelle A e B, ciascuno con un ID e una tabella chiamata a_b che ha una tupla chiave esterna di (a_id, B_ID). Ma dovrebbe a_b avere una colonna ID auto-increment chiave primaria della propria, o no?

Quali sono i vantaggi e gli svantaggi di aggiungerlo? Personalmente, come chiavi naturale per molti-a-molti si unisce. Ma ciò che ha aggiunto vantaggio sarebbe una chiave primaria add?

Answer 1

Sono d'accordo con tutto quello che ha detto Oded tranne

"E non può ragionevolmente essere utilizzato come chiave esterna sia ".

In questo caso si tratta di un pick tuo veleno, la tabella di mapping può assolutamente essere un genitore, è solo una questione del bambino utilizzando un più colonne FK oppure no.

Prendere un caso semplice di auto e del colore. Ogni auto Makers quest'anno hanno una certa gamma di colori e ogni modello viene solo in numero limitato di quei colori. Molti - Molti :: Colori a modelli Auto

Così ora progettare la tabella Order in cui sono memorizzati automobili nuovi ordini. Chiaramente colore e modello saranno sul tavolo dell'Ordine. Se si commette un FK a ciascuno di tali tabelle, il database consentirà una combinazione di modello / colore non corretto da selezionare. (Naturalmente è possibile applicare questo con il codice, non si può fare in modo dichiarativo.) Se si effettua il genitore sia i tanti: tavolo molti, si otterrà solo le combinazioni che sono stati specificati.

SO preferireste avere un più colonne FK e puntare a un PK costruita su entrambi ModelID e ColorID o volete una singola colonna FK?

Scegli il tuo veleno.

Modifica

Ma se non è un genitore di qualcosa, senza tavolo ha bisogno di una chiave surrogata.

Answer 2

Un tale chiave surrogata aggiunge nulla se non in testa.

Utilizzare i tasti naturali, li rendono una chiave primaria composta, se vi preoccupate per la duplicazione in questa tabella.

Per espandere:

Nella domanda, questa chiave sarà priva di significato e rimarrà inutilizzato.

Nel database, avrà alcuna funzione, come non si può ragionevolmente utilizzare in una query per qualsiasi tipo di risultato significativo.

Non può ragionevolmente essere utilizzato come una chiave esterna sia.

Answer 3

ho fatto entrambe le cose. A volte è utile per l'aggiunta di una funzione lungo la strada. Per esempio, se ci fosse mai una volta che una riga nella tabella avrebbe mai contenere qualcosa di più di un semplice 2 id. Se non manca lo spazio avrei messo uno in là solo perché non può far male. A volte può interferire con strumenti ORM come Hibernate o ADO.NET ma che è minore.

Quindi, per riassumere ... PROFESSIONISTI 1. Permette potenziale di crescita futura.

CONS 1. Spazio 2. Confonde alcuni strumenti ORM.

Answer 4

Il termine "join tabella" è spesso usato, ma non credo che abbia mai visto correttamente definito o spiegato. Personalmente evito di usare quel termine. A quanto ho capito, un "join tabella" si intende qualsiasi tavolo con due chiavi esterne (o forse più di due?).

Credo che i criteri per la selezione chiavi in ??una tabella con più di una chiave esterna dovrebbe essere più o meno lo stesso come in qualsiasi altra tabella. Chiedetevi che cosa dipendenze è necessario rispettare, ciò che è unico e irriducibile. Seleziona i tasti sui criteri di familiarità, stabilità e semplicità. Aggiungere chiavi surrogate solo quando si ha un buon motivo per farlo.

Answer 5

E 'in realtà non fornisce nulla di utile. Tenete a mente lo scopo di una chiave, che è quello di riferirsi unicamente a "qualcosa". Una tabella di associazione come questo non è di per sé "qualcosa", ma è piuttosto la persistenza struttura per le altre due "quarantina", che già hanno le chiavi. Al di fuori della media persistenza (il database) non ha un significato e non dovrebbe nemmeno esiste veramente o essere conosciuto (come nel dominio aziendale), quindi non ci sarebbe (dovrebbe) essere alcuna ragione per riferirsi ad esso il proprio ID.