Nel contesto delle relazioni di database annidate (A-B-C), quali sono le considerazioni per avere una chiave esterna aggiuntiva "a scelta rapida" (A-C)?

Question

Nel contesto delle relazioni di database annidate (A-B-C), quali sono le considerazioni per avere una chiave esterna aggiuntiva "a scelta rapida" (A-C)?

#1 da (4 voti)

1

Ho un database relazionale normalizzato. Trovo spesso che ho bisogno di attraversare più tabelle per ottenere l'oggetto correlato di un oggetto correlato e così via.

Quindi intendo dire che ho tabelle correlate A- > B- > C- > D. In un processo che utilizza sia A che D, questa potrebbe essere una traversata molto costosa per passare da A a D. Sto pensando di aggiungere una seconda chiave esterna su A per cui ho A- > B e A- > D. L'unico problema che vedo qui è la potenziale incoerenza delle chiavi (cosa succede se il valore B viene aggiornato ma non D).

Quali sono i pro e i contro e le considerazioni di fare questo tipo di doppio collegamento?

Alcuni contesti specifici: sto utilizzando Django ORM e postgreSQL per le operazioni del database.

database database-design postgres

posta Jad S 14.06.2018 - 21:08

fonte

1 risposta

Leggi altre domande sui tag database database-design postgres

Duplicazione di una chiave in una tabella di mappatura invece di unirsi Come definire una classe di sistema?

score 4 · Answer 1

I professionisti di questo approccio sono:

la facilità di un accesso diretto all'oggetto connesso se non hai bisogno degli oggetti nel mezzo;
potenziale miglioramento delle prestazioni dovuto alla riduzione dei join (ma con il motore di ottimizzazione dei moderni RDBMS, questo guadagno potrebbe essere marginale)

I contro sono tutti gli aspetti negativi della denormalizzazione:

hai dati ridondanti
devi mantenere questi dati sincronizzati. Più oggetti ci sono nel mezzo, più difficile sarà mantenere la sincronizzazione.
Creazione di colli di bottiglia di concorrenza: ogni modifica sugli oggetti nel mezzo potrebbe richiedere un aggiornamento dell'oggetto A, che può causare problemi di blocco se diversi processi / utenti sono all'origine della modifica sugli oggetti intermedi.
Complessificazione / duplicazione del codice: ad es. se B ha un qualche tipo di stato (es. "DELETED", "SUSPENDED" o "INACTIVE) che influisce sull'accessibilità di C e D per A, è necessario replicare questa funzione nel codice che mantiene la sincronizzazione. per analizzare non solo le relazioni tecniche tra i dati, ma anche la logica di business che è dietro di esso.

Infine, prima di considerare la denormalizzazione, è necessario analizzare la relazione tra A e D, per sapere dove è necessario aggiungere la chiave esterna. Se è 1 a 1, puoi aggiungerlo in A (ma D esiste già quando crei un A?). Ma se è uno su molti, non puoi considerare la duplicazione di righe, quindi dovrai aggiungere una chiave esterna a A in D (stessa domanda: l'A generalmente esiste quando D viene creato?).

Personalmente, temo che i contro della denormalizzazione superino i professionisti, specialmente quando si pensa a problemi di concorrenza, ma per analizzare le dinamiche dietro le tabelle è necessaria un'analisi più approfondita con le misurazioni (es. numero di letture vs. numero di scritture) per conoscere i fatti oggettivi.