Qualche buona letteratura sulla performance di join vs denormalizzazione sistematica?

Question

Come corollario di questa domanda mi chiedevo se ci è stato un buon studio comparativo che ho potuto consultare e trasmettere sui vantaggi dell'utilizzo di RDMBS per l'ottimizzazione del join e la denormalizzazione sistematica per accedere sempre a una singola tabella alla volta.

In particolare, voglio informazioni su:

• Prestazioni o normalizzazione contro 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 sto andando qui: 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 utilizzi sempre una singola tabella, viene utilizzata una denormalizzazione sistematica pesante su tutte le tabelle, a volte appiattendo due o tre livelli di profondità. Per quanto riguarda la relazione n-n, sembra che abbiano aggirato il problema 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 troppo complesso e contorto in cui il cliente si lamenta spesso delle prestazioni. Quando analizzano un tale collo di bottiglia, non mettono mai in discussione queste premesse di base su cui si basa il sistema e cercano sempre altre soluzioni.

Mi sono perso qualcosa? Penso che l'idea sia sbagliata, ma in qualche modo mancano le prove inconfutabili per dimostrarla (o confutare), è qui che mi rivolgo alla tua saggezza collettiva per indirizzarmi verso una buona letteratura ben accettata che possa convincere gli altri nella mia squadra questo l'approccio è sbagliato (per convincermi che sono troppo paranoico e dogmatico riguardo a modelli di dati coerenti).

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

---- 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 usando Oracle. Non hanno effettuato il refactoring ma hanno semplicemente aggiunto il supporto per i database relazionali al sistema esistente. Il supporto per file flat è stato successivamente abbandonato, ma stiamo ancora aspettando che i refactor possano sfruttare i vantaggi del database.

Answer 1

un pensiero: hai una chiara corrispondenza di impedenza, un livello di accesso ai dati che consente l'accesso a una sola tabella? Basta qui, 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 se non quella di restituire una singola tabella, e presumibilmente fare unirsi al livello bausiness, semplicemente non ha senso.

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

Prevedo che l'analisi comparativa di questo tipo di cose sarà un'attività senza fine, casi speciali abbonderanno. Sostengo che la normalizzazione è "normale", le persone ottengono prestazioni abbastanza buone da un progetto di 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, Modellazione dimensionale è l'unica tecnica di denormalizzazione sistematica che ha qualche teoria dietro. Questa è la base delle tecniche di data warehousing .

DM è stato lanciato per la prima volta da Ralph Kimball in " A Dimensional Modeling Manifesto " nel 1997. Kimball ha anche scritto una serie di libri. Il libro che sembra avere le recensioni migliori è " The Data Warehouse Toolkit: The Complete Guide alla modellazione dimensionale (seconda edizione) " (2002), anche se non l'ho ancora letto.

Non c'è dubbio che la denormalizzazione migliora le prestazioni di determinati tipi di query, ma lo fa a spese di altre query. Ad esempio, se hai una relazione molti-a-molti tra, diciamo, Prodotti e Ordini (in una tipica applicazione di e-commerce) e hai bisogno che sia più veloce per interrogare i Prodotti in un dato Ordine, allora puoi archiviare i dati in un modo denormalizzato per sostenerlo e ottenere qualche beneficio.

Ma ciò rende più imbarazzante e inefficiente interrogare tutti gli ordini per un determinato prodotto. Se hai la stessa necessità di effettuare entrambi i tipi di query, dovresti attenersi al design normalizzato. Questo colpisce un compromesso, offrendo a entrambe le query prestazioni simili, anche se nessuna delle due sarà tanto veloce quanto lo sarebbe nella progettazione denormalizzata che favoriva un tipo di query.

Inoltre, quando si archiviano i dati in modo denormalizzato, è necessario svolgere un lavoro extra per garantire coerenza. Cioè nessuna duplicazione accidentale e nessuna integrità referenziale rotta. Devi considerare il costo dell'aggiunta di controlli manuali per coerenza.