Tabelle di intersezione multiple vs join multipli
Ho una relazione gerarchica tra le mie tabelle, con i bambini che hanno chiavi esterne che si riferiscono ai loro ID genitore (supponendo che id
sia la chiave primaria per ogni tabella):
Department
ha molti Category Group
s
Category Group
ha molti Category
(-ies)
Category
ha molti Sub-Category
(-ies)
Sub-Category
ha molti Attribute
s.
Ora, tutte queste entità eccetto Attribute
s hanno un significato facoltativo se non seleziono nulla nella mia interfaccia utente basata su menu a discesa gerarchico a cascata, devo visualizzare le Attribute
s che appartengono a tutte le Department
s, se seleziono solo una Department
allora devo visualizzare le Attribute
s che appartengono a tutti gli Category Group
appartenenti a quello Department
e così via.
Ovviamente, un'opzione per implementarlo è fare un inner join tra tutte le tabelle a cui arrivare Attribute
. Ad esempio, se non è selezionato nulla, sarà:
Department
inner join Category Group
inner join Category
inner join Sub-Category
inner join Attribute
per mostrare tutti gli attributi appartenenti a tutti i reparti.
L'altro pensiero nella mia testa è di avere intersezione / relazione tabella di mappatura (s) -
DepartmentAttributeRelation
che ha le chiavi esterne a Department
e Attribute
,
CategoryGroupAttributeRelation
che ha le chiavi esterne per CategoryGroup
e Attribute
e così via.
Ciò consentirà alla ricerca diretta di raggiungere Attribute
i dati di qualsiasi entità.
La mia domanda è: ci sono degli svantaggi nel secondo approccio di cui sopra o ci sono approcci migliori per risolverlo?
Risposte
Qual è il problema con l'unione interna? Crea una vista in modo da non dover mai più vedere o scrivere di nuovo la brutta query multi-join.
Il primo e più importante svantaggio dell'alternativa è che puoi avere incongruenze, cioè puoi avere dati in quelle "tabelle di join" che potrebbero potenzialmente contraddirsi, cioè sono possibili anomalie di inserimento. Dovresti scrivere del codice per evitare che si verifichino tali anomalie.
Tieni presente, tuttavia, che a volte quando si crede che una gerarchia sarà per sempre a molto, diciamo, 4 livelli di profondità, allora un requisito si presenta quando è necessaria una sottocategoria e il design della gerarchia a livello fisso si interrompe. Una soluzione a prova di futuro in cui può esserci una profondità sconosciuta dei livelli di gerarchia e solo gli elementi "foglia" possono avere attributi è questione di un'altra domanda e di un'altra risposta.