Qualunque buona letteratura sul rendimento delle prestazioni rispetto alla denormalizzazione sistematica?

Question

Come corollario a this question Mi chiedevo se esistessero buoni studi comparativi che potevo consultare e trasmettere sui vantaggi dell'utilizzo dell'RDMBS fare l'ottimizzazione dell'aggregazione vs denormalizzare sistematicamente per accedere sempre a una singola tabella alla volta.

In particolare voglio informazioni su:

• Performance o normalizzazione rispetto denormalizzazione.
• Scalabilità del sistema normalizzato vs denormalizzato.
• Problemi di manutenibilità della denormalizzazione.
• problemi di coerenza del modello con denormalizzazione.

Un po 'di storia per vedere dove vado: il nostro sistema utilizza un livello di astrazione del database interno, ma è molto vecchio e non può gestire più di una tabella. Pertanto, tutti gli oggetti complessi devono essere istanziati utilizzando più query su ciascuna delle tabelle correlate. Ora per essere sicuri che il sistema usi sempre una singola tabella, la denormalizzazione sistematica viene usata in tutte le tabelle, a volte spianando due o tre livelli in profondità. Per quanto riguarda la relazione n-n, sembra che abbiano lavorato attorno ad essa elaborando attentamente il loro modello di dati per evitare tali relazioni e ricadere sempre su 1-n o n-1.

Il risultato finale è un sistema complicato e complesso in cui i clienti si lamentano spesso delle prestazioni. Analizzando tale collo di bottiglia, non mettono mai in dubbio queste premesse di base su cui si basa il sistema e cercano sempre un'altra soluzione.

Mi sono perso qualcosa? Penso che l'intera idea sia sbagliata, ma in qualche modo manca l'evidenza inconfutabile per provare (o smentire), è qui che mi sto rivolgendo alla tua saggezza collettiva per indicarmi una letteratura buona, ben accettata, che possa convincere gli altri della mia squadra a questo approccio è sbagliato (di convincermi che sono troppo paranoico e dogmatico su modelli di dati coerenti).

Il mio prossimo passo è costruire il mio banco di prova e raccogliere i risultati, dal momento che odio reinventare la ruota Voglio sapere cosa c'è già sul tema.

---- EDIT Note: il sistema è stato inizialmente creato con file flat senza un sistema di database ... solo successivamente è stato portato su un database perché un client ha insistito sul sistema che utilizza Oracle. Non hanno refactoring, ma hanno semplicemente aggiunto il supporto per i database relazionali al sistema esistente. Il supporto di file flat è stato successivamente abbandonato, ma siamo ancora in attesa di refactoring per sfruttare i vantaggi del database.

Answer 1

un pensiero: si ha un'errata corrispondenza di impedenza, un livello di accesso ai dati che consente l'accesso a una sola tabella? Basta fermarsi lì, questo è semplicemente incoerente con l'uso ottimale di un database relazionale. I database relazionali sono progettati per eseguire query complesse molto bene. Non avere altra scelta che restituire una singola tabella, e presumibilmente fare qualsiasi adesione nel livello bausiness, non ha senso.

Per giustificare la normalizzazione e i costi di coerenza potenziali è possibile fare riferimento a tutto il materiale da Codd in poi, vedere Wikipedia article.

Prevedo che il benchmarking di questo tipo di cose sarà un'attività senza fine, i casi speciali abbonderanno. Io sostengo che la normalizzazione è "normale", le persone ottengono prestazioni abbastanza buone da un deisgn database pulito. Forse un approccio potrebbe essere un sondaggio: "Quanto sono normalizzati i tuoi dati? Scala da 0 a 4."

Answer 2

Per quanto ne so, Dimensional Modeling è l'unica tecnica di denormalizzazione sistematica che ha qualche teoria dietro di esso. Questa è la base di data warehousing tecniche.

DM è stato lanciato da Ralph Kimball in" A Dimensional Modeling Manifesto "nel 1997 Kimball ha anche scritto una serie di libri Il libro che sembra avere le migliori recensioni è "The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling (Second Edition)" (2002), anche se non l'ho ancora letto

Non c'è dubbio che la denormalizzazione migliora le prestazioni di certi tipi di query, ma lo fa a spese di altre query. Ad esempio, se si ha una relazione molti-a-molti tra, ad esempio, Prodotti e ordini (in una tipica applicazione e-commerce), e hai bisogno che sia il più veloce per interrogare i Prodotti in un determinato Ordine, puoi quindi archiviare i dati in modo denormalizzato per supportarli e ottenere qualche vantaggio.

Ma ciò rende più scomodo e inefficiente interrogare tutti gli ordini per un determinato prodotto. Se hai la stessa necessità di effettuare entrambi i tipi di query, dovresti mantenere il design normalizzato. Questo giunge a un compromesso, offrendo a entrambe le query prestazioni simili, anche se nessuna delle due sarà veloce come sarebbe nella progettazione denormalizzata che ha favorito un tipo di query.

Inoltre, quando si memorizzano i dati in modo denormalizzato, è necessario eseguire un lavoro supplementare per garantire la coerenza. Cioè nessuna duplicazione accidentale e integrità referenziale rotta. È necessario considerare il costo dell'aggiunta di controlli manuali per coerenza.