Attualmente ho un database con due tabelle chiamate Articoli e tag. Per consentire agli articoli di essere in più categorie ho una relazione molte a molte. È un errore avere un tale design in termini di prestazioni? o devo rimuovere la relazione tra queste due tabelle e aggiungere una terza tabella come bridge (articleTags)?relazione molti-a-molti nella progettazione del database
Non c'è niente di intrinsecamente sbagliato con avere una relazione molti-a-molti, avrete solo bisogno di creare un Junction Table (che è quello che suona come ti riferisci con articlesTags) per facilitare quel rapporto.
Non c'è alcun problema nell'avere una relazione molti-a-molti se questo è ciò che richiedono i dati, ma vorrai una terza tabella per rappresentarla.
Direi "avrai bisogno di un terzo tavolo". – Dave
Una relazione molti-a-molti esiste in un modello relazionale, è solo un'astrazione della mente. Quando implementeremo che ci sarà un tavolo articles_to_tags dove avrete:
fk_article (intero) fk_tag (intero)
Non c'è nessun problema nel usando molti a molte relazioni. È spesso richiesto.
E sì, non è possibile creare una relazione molti a molti, senza utilizzare una terza tabella.
Stai vedendo la differenza tra un progetto di database concettuale (la relazione N: N) e la sua realizzazione fisica. Indipendentemente da come modellate la vostra relazione N: N, avrete bisogno della suddetta tabella di giunzione per farlo funzionare.
Non c'è niente di sbagliato nel modellare un rapporto del mondo reale il più vicino possibile al mondo reale, come è possibile in generale. La chiarezza è il re.
Quando si tratta di domande relative alle prestazioni in qualsiasi sistema, la risposta di solito si riduce a "dipende".
Se il tuo problema di prestazioni è correlato a WRITES, allora una struttura altamente NORMALIZZATA è la migliore e vorresti quella tabella di giunzione. Finirai per scrivere molto meno dati e questo può velocizzare le cose in modo sostanziale (sebbene tu possa bruciare questo vantaggio, dovendo fare ricerche prima di creare gli inserti). Anche la lettura dei singoli tavoli normalizzati può essere molto veloce.
Se il problema è correlato a READS analitici, una struttura DENORMALIZZATA è la migliore. Le join possono essere molto performanti se i tavoli sono grandi e gli indici sono distribuiti. Sacrificerai molto spazio per guadagnare molto tempo.
In generale, si desidera esaminare le specifiche della propria situazione e valutare i pro e i contro di ciascun approccio prima di decidere una soluzione. Personalmente, ho sempre trovato preferibile concentrarmi su Clarity nelle fasi iniziali e refactoring per le prestazioni se scopro un problema in seguito.
Come hai creato una relazione molti-a-molti senza l'uso di una tabella articoliTags? – flayto
Se si ha una relazione molti-a-molti, è necessario rappresentare la terza tabella: non esiste un'alternativa ragionevole. L'approccio più vicino potrebbe essere una struttura SET in ogni tabella, se il tuo DBMS lo supporta. Ma in genere non c'è molto controllo tra tabelle su tali tipi - la tabella separata è necessaria. –