Risposte:
Dovresti andare fino in fondo e non oltre. Ovviamente. ~ Il problema potrebbe essere che questo è un po 'un'arte, ed è per questo che questa non è una scienza pura.
Il nostro prodotto principale è un sistema di analisi e rendicontazione, e quindi a tale riguardo, disponiamo di alcuni record di dettagli. Inizialmente l'abbiamo progettato con molti join su un ID comune per alcuni dei record figlio, ma abbiamo scoperto che se avessimo denormalizzato un paio di campi avremmo potuto tagliare MOLTI join e potremmo eliminare molti mal di testa nelle prestazioni.
Ma lo sapevamo solo perché 1) abbiamo creato un design "normalizzato", 2) abbiamo iniziato a usarlo, 3) abbiamo profilato le prestazioni effettive dopo centinaia di milioni di righe su dozzine di tabelle.
La storia finale è che fino alla profilazione non potevamo sapere con certezza cosa avrebbe funzionato per noi. Ci è piaciuta l'idea di normalizzare in modo da poter aggiornare più facilmente, ma alla fine le prestazioni effettive sono state il fattore decisivo. Questo è il mio consiglio per te: profilo, profilo, profilo.
in ('forgiven','pardoned');): p
La normalizzazione è un obiettivo solo quando supporta il tuo modello di dati abbastanza bene da giustificarlo. È pensato per essere una guida per consentire crescita, gestione e manutenibilità. Ricorda che il libro sulla normalizzazione, né i suoi autori costruiranno o manterranno il tuo database o la sua applicazione.
Una buona lettura sul tema della "troppa normalizzazione" è qui.
E sì, ci possono essere impatti sulle prestazioni a troppa normalizzazione. Questo sarebbe in un attraversamento più profondo della tabella per raccogliere cose come le tabelle degli indicatori di stato quando sono state estratte in una tabella separata. Alcuni diranno che questo è di solito negato nella velocità di aggiornamento (cambiando il testo dello stato da "Buono" a "BUONO" o qualcosa di simile) o nella manutenibilità.
Consiglio di leggere la seguente appendice trovata in alcuni dei libri più recenti di Chris Date :
Due applausi per la normalizzazione
La normalizzazione è lungi dall'essere una panacea, come possiamo facilmente vedere considerando quali sono i suoi obiettivi e quanto bene si confronta con loro ...
Devo chiarire che non voglio che i miei commenti in questa sezione vengano visti come un qualsiasi tipo di attacco. Credo fermamente che qualcosa di meno di un design completamente normalizzato sia fortemente controindicato ...
Penso che sia altrettanto importante esaminare le denormalizzazioni esplicite aggiunte, i valori aggregati aggiunti o alcuni campi da una tabella principale copiati in una copia di dettaglio.
L'argomento è principalmente un argomento di prestazione.
In tal caso, i campi vengono aggiornati dai trigger e spetta al database mantenerli coerenti.
Sono totalmente d'accordo con @jcolebrand. Quando si progetta un modello per l'applicazione, è necessario normalizzare tutto ciò che è possibile. Ma poi dovresti profilare le query costruite sul tuo modello, specialmente quelle eseguite frequentemente.
Esperienza personale: gli attributi che sono stati raggiunti da due join (il che significa che tre tabelle sono state unite) saranno principalmente un vantaggio per le prestazioni. E per peggiorare le cose, viene utilizzato nelle transazioni online. Denormalizzo l'attributo, quindi ho solo bisogno di un join e ho chiesto al programmatore di modificare la propria app per la query e l'aggiornamento dell'attributo. Ora funziona molto meglio ...
In altre parole, dovresti bilanciare la normalizzazione con le prestazioni.