Perché avere una tabella di join per la relazione 1: m in SQL

Question

Qual è il vantaggio di avere tabelle di giunzione tra la prima relazione 1:m e la seconda relazione 1:m nel seguente database?

testo alternativo http://dl.getdropbox.com/u/175564/db/db-simple.png

Il libro Alberi e gerarchie di Joe Celko in SQL per Smarties dice che il motivo è avere relazioni uniche in 1:m.Ad esempio, le tabelle seguenti limitano gli utenti a porre esattamente la stessa domanda due volte e a fornire esattamente la stessa risposta due volte, rispettivamente.

La prima relazione 1:m

users-questions
===============
user_id REFERENCES users( user_id )
question_id REFERENCES questions ( question_id )
PK( user_id, question_id)           // User is not allowed to ask same question twice 

La seconda relazione 1:m

questions-answers
=================
question_id REFERENCES questions( question_id)
answer_id REFERENCES answers( aswer_id )
PK( question_id, answer_id )       //  Question is not allowed to have to same answers

Questo vantaggio sull'unicità non mi convince a rendere il mio codice più impegnativo.Non riesco a capire perché dovrei limitare la possibilità di avere domande o risposte con lo stesso ID nel db, visto che forse posso usare PHP per vietarlo.

Answer 1

Il suo solito a causa della duplicazione dei dati.

Per quanto riguarda il tuo ragionamento, sì, si può applicare il presente nel livello di business, ma se si commette un errore, si potrebbe rompere una notevole quantità di codice. Il problema che hai è il tuo modello di dati può avere solo pochi tavoli. Sei fortunato. Quando il vostro modello di dati cresce, se non si può dare un senso della struttura e si deve mettere tutta la logica per mantenere le tabelle denormalizzato nel vostro livello di interfaccia grafica si potrebbe facilmente incorrere in problemi. Si noti che è difficile fare le cose threadsafe su una GUI per il database SQL senza l'utilizzo di bloccaggio che distruggerà la vostra performance.

DBMS sono molto molto bravo a trattare con questi problemi. È possibile mantenere il vostro modello di dati pulito e utilizzare l'indicizzazione per fornire la velocità necessaria. Il vostro obiettivo dovrebbe essere quello di farlo bene prima, e solo denormalise le tabelle quando si può vedere una chiara necessità di farlo (per le prestazioni, ecc)

Che ci crediate o no, ci sono molte situazioni in cui disporre di dati normalizzati rende la vita più facile, non più difficile quando si tratta di vostra applicazione. Per esempio, se si dispone di un grande tavolo con domande e risposte, si deve scrivere il codice per controllare se è unico nel suo genere. Se si dispone di una tabella con una chiave primaria, è sufficiente scrivere

insert into table (col1, col2) values (@id, @value) --NOTE: You would probably 
--make the id column an autonumber so you dont have to worry about this

La banca dati vi impedirà di inserire se si dispone di un valore non unica lì o se si sta mettendo in una risposta con nessuna domanda. Tutto quello che dovete fare è controllare se l'inserimento ha funzionato, niente di più. Quale pensi sia meno codice?

Answer 2

Bene, la cosa unica rapporti sembra privo di senso per me, probabilmente perché io sono abituato a DBMS in cui è possibile definire chiavi univoche diversi la chiave primaria. Nel mio mondo, tabelle di mappatura come quelli sono come implementare una relazione molti-a-molti, e li utilizzano per una relazione uno-a-molti è una follia - Voglio dire, se si fa questo, forse si ha intenzione per la relazione da utilizzare come uno-a-molti, ma quello che hai effettivamente implementato è molti-a-molti supporto.

Non sono d'accordo con quello che dici riguardo vi sia alcuna utilità per chiavi composte uniche al strato di persistenza, perché si può far valere che nel livello di applicazione, però. Persistenza-layer vincoli unicità hanno un sacco di difficile da replicare benefici, come ad esempio, in MySQL, la possibilità di usufruire di INSERT ... ON DUPLICATE KEY UPDATE .

Answer 3

Sono d'accordo sul fatto che la tabella di join per uno-a-molti in questa situazione non sembra aggiungere molti vantaggi e, come dice @chaos, in realtà si finisce per implementare il supporto molti-a-molti.Ma Joe Celko è un ragazzo intelligente: è davvero questa la risposta esatta che dà?

Un altro possibile motivo per implementare una tabella di join su uno-a-molti è che separa completamente le domande/risposte dalla dipendenza dagli utenti.

Ad esempio, supponiamo che tu abbia aggiunto a Dogs tavoli e un Deities tavolo.Sappiamo tutti che i cani non possono registrarsi come utenti perché non hanno indirizzi e-mail, e gli dei non si registrano come utenti perché, beh, è ​​una cosa al di sotto delle loro capacità.Forse i cani e gli dei fanno ancora domande, ma per farlo potresti voler implementare una tabella delle domande sui cani e una tabella delle domande sulle divinità.In teoria questo è ancora molti a molti, ma in pratica lo fai in modo da poter avere più uno a molti.