È denormalizzante una struttura dati essenzialmente un'ottimizzazione del codice, a cui si applicano le normali regole?

Il problema che ho con quelle regole è che stanno parlando ai bambini. Arriva un momento in cui è necessario trovare accelerazioni, e quando fa cliché non aiuterà. Devi sapere come si fa.

Indovinare non li trova. Se qualcuno guarda il codice e dice "forse questo potrebbe essere fatto meglio" - questo è indovinare.

La misurazione non li trova. Potrebbe dirti che c'è un problema no , ma se ce n'è uno, non ti dice di cosa si tratta.

Alcune persone sono più utili, dicendo "usa un profiler". I profiler possono darti una bella carta da parati, ma trovano solo una classe limitata di speedup . Se lasci che gli altri se ne vadano, ti perderai tutto - gran tempo. Ecco perché.

C'è un metodo che alcune persone usano . Non ti dà una bella carta da parati. Trova eventuali accelerazioni che fanno i profiler e più che non lo fanno.

Le regole di Bloch sull'ottimizzazione sono solo una variazione su "l'ottimizzazione prematura è la radice di tutti i mali" che, correttamente interpretato, significa "Misura prima, prima di ottimizzare. Assicurati che l'ottimizzazione ti fornisca effettivamente il vantaggio in termini di prestazioni stai cercando, prima di spendere tempo e denaro per l'ottimizzazione. "

Non sono necessariamente d'accordo con il ritardare tutte le ottimizzazioni fino alla fine del progetto. Alcune ottimizzazioni devono essere fatte durante lo sviluppo; aspettare fino alla fine rende tali ottimizzazioni effettivamente impossibili.

Sto scrivendo questo per sottolineare che la normalizzazione non è solo per l'ottimizzazione. Ci sono casi in cui RDBMS non è la soluzione corretta per il problema in questione e possono essere utilizzati database di documenti o persino file system per memorizzare le tue informazioni. Tuttavia, non è intenzione di questa risposta entrare in questo.

La normalizzazione promuove l'ottimizzazione ma non è solo per l'ottimizzazione. La normalizzazione (se eseguita correttamente) genera informazioni coerenti a livello di archivio dati. Questo tipo di coerenza è altamente auspicabile in molti sistemi OLTP. Ha un costo per i sistemi di BI basati su grandi quantità di dati, quindi approcci alternativi come gli schemi a stella sono disponibili per tali sistemi.

Ad esempio, data un'applicazione CMS basata sul Web, quando un cliente modifica il suo indirizzo, tutti i riferimenti a quel cliente a livello di database punteranno alle informazioni sull'indirizzo più recenti (o più recenti).

Inoltre, SQL funziona in completa armonia con la normalizzazione per fornire questo tipo di informazioni coerenti. Puoi sfruttare appieno le funzioni aggregate, i join, ecc. Con una struttura normalizzata, quindi ridurre la complessità del codice.

Gli strumenti di generazione dei report funzionano anche molto bene con le strutture normalizzate.

Per le applicazioni aziendali, la normalizzazione è così importante che l'integrazione dei sistemi diventa più semplice.

In sintesi, la normalizzazione ha altri vantaggi rispetto all'ottimizzazione.