La normalizzazione del database è morta? [chiuso]

Sono stato educato alla vecchia scuola - dove abbiamo imparato a progettare lo schema del database PRIMA del livello aziendale dell'applicazione (o usando OOAD per tutto il resto). Sono stato abbastanza bravo a progettare schemi (IMHO :) e normalizzato solo per rimuovere la ridondanza non necessaria, ma non dove ha influito sulla velocità, ad esempio se i join sono stati un impatto sulle prestazioni, la ridondanza è rimasta al suo posto. Ma soprattutto non lo era.

Con l'avvento di alcuni framework ORM come ActiveRecord di Ruby o ActiveJDBC (e alcuni altri che non ricordo, ma sono sicuro che ce ne sono molti) sembra che preferiscano avere una chiave surrogata per ogni tabella anche se alcuni hanno chiavi primarie come 'e-mail' - rompendo completamente 2NF. Va bene, capisco non troppo, ma mi dà sui nervi (quasi) quando alcuni di questi ORM (o programmatori) non riconoscono 1-1 o 1-0 | 1 (cioè da 1 a 0 o 1). Stabiliscono che è semplicemente meglio avere tutto come un grande tavolo, non importa se ha un sacco di nulls "i sistemi di oggi possono gestirlo" è il commento che ho sentito più spesso.

Concordo sul fatto che i vincoli di memoria presentavano una correlazione diretta con la normalizzazione (ci sono anche altri vantaggi :) ma ai giorni nostri con memoria a buon mercato e macchine quad-core il concetto di normalizzazione dei DB è appena lasciato ai testi? Come DBA pratichi ancora la normalizzazione su 3NF (se non su BCNF :)? Importa? Il design "schema sporco" è buono per i sistemi di produzione? Proprio come si dovrebbe rendere il caso "per" normalizzazione se è ancora rilevante.

( Nota: non sto parlando degli schemi stella / fiocco di neve di datawarehouse che hanno ridondanza come parte / necessità del design, ma sistemi commerciali con un database back-end come StackExchange per esempio)

Un motivo per la normalizzazione è rimuovere le anomalie di modifica dei dati che gli
ORM di solito non supportano.

Ho molti esempi di database progettati da Hibernate che infrangono questo principio:

• gonfio (stringa ripetuta per oltre 100 di milioni di righe)
• nessuna tabella di ricerca (vedi sopra)
• nessun DRI (vincoli, chiavi)
• indici cluster varchar
• tabelle di collegamenti non necessarie (ad es. applicazione 1..0: 1 quando sarebbe sufficiente una colonna FK nullable)

Il peggio che ho visto è un database MySQL da 1 TB che era forse il 75-80% troppo grande a causa di questi

Suggerirei anche che l'affermazione "i sistemi di oggi possono gestirlo" è vera per la maggior parte dei sistemi di Topolino. Mentre scala, i sistemi di oggi non lo faranno.

Nel mio esempio sopra, non c'era trazione per il refactoring o la modifica delle chiavi o la correzione dei dati: basta lamentarsi dei tassi di crescita del database e dell'incapacità di costruire un DW significativo su di esso

sembra che preferiscano avere una chiave surrogata per ogni tavolo anche se alcuni hanno chiavi primarie come "email" - rompendo completamente 2NF.

Le chiavi surrogate non rompono 2NF. 2NF dice "Se una colonna dipende solo da una parte di una chiave multivalore, rimuovi quella colonna in una tabella separata."

Stabiliscono che è semplicemente meglio avere tutto come un grande tavolo, non importa se ha una tonnellata di null

La presenza di più colonne in una tabella è valida purché vengano seguite le regole di normalizzazione. Non è corretto unire le tabelle senza analisi se si desidera sfruttare i vantaggi di SQL e normalizzazione.

Concordo sul fatto che i vincoli di memoria presentavano una correlazione diretta con la normalizzazione. Le forme normali di relazione sono un concetto matematico e non hanno nulla a che fare con la memoria.

La normalizzazione è lì non solo per risparmiare memoria o disco, ma è lì per aggiungere integrità. Dopotutto è un concetto matematico indipendente dall'hardware.

Esempio semplice: supponi di mantenere le informazioni sulla scuola come:

Rec 1: North Ridge High School, California, USA

Rec 2: South Toronto Braves High School, Ontario, Canada

Se chiedi al tuo sistema dove si trova l'Ontario, puoi scoprire che si trova in Canada. Pochi giorni dopo elimini la seconda fila e fai al sistema la stessa domanda e non ottieni nulla. In questo esempio, non importa quanto spazio su disco, memoria o CPU, non otterrai la risposta.

Questa è un'anomalia che normalizza le relazioni che aiutano a prevenire.

Modifica: ho cambiato la parola Toronto in Ontario come da commento qui sotto.

Più le cose cambiano, più rimangono le stesse. Ci sono sempre stati sviluppatori pigri che hanno tagliato gli angoli o semplicemente non sanno o vogliono seguire le migliori pratiche. Molte volte riescono a cavarsela in applicazioni più piccole.

In passato confondeva le strutture di dati ispirate a COBOL nei primi RDBMS, o nel disastro di Dio che era dBase. Ora sono ORM e "Code-First". Alla fine, questi sono tutti modi in cui le persone cercano di trovare il proiettile d'argento per ottenere un sistema funzionante senza "perdere" tempo a pensare intensamente a ciò che vuoi e che devi fare. Essere di fretta è sempre stato un problema e sarà sempre un problema.

Per coloro che hanno il buon senso (e la fortuna) di dedicare del tempo a progettare correttamente, il modello di dati sarà sempre il punto più logico per iniziare. Ciò che va nel database sono informazioni sulle cose (tangibili e intangibili) a cui la tua azienda tiene. Ciò che interessa alla tua azienda cambia molto meno rapidamente di come opera la tua azienda. Questo è il motivo per cui il tuo database è generalmente molto più stabile del tuo codice.

Il database è il giusto fondamento di qualsiasi sistema e impiegare il tempo per gettare le basi in modo corretto ti porterà inevitabilmente a lungo termine. Ciò significa che la normalizzazione sarà sempre un passaggio importante e utile per qualsiasi applicazione di tipo OLTP.

Concordo sul fatto che i vincoli di memoria presentavano una correlazione diretta con la normalizzazione ...

I vincoli di memoria sono ancora importanti. La quantità non è un problema, la velocità lo è.

• Le CPU non stanno andando più veloce al momento (stiamo ottenendo più core, non cicli al secondo)
• Le architetture CPU moderne tentano di superare i limiti di velocità fornendo memoria separata per ciascun processore ( NUMA ).
• Le dimensioni della cache on-die non crescono a una velocità comparabile alla memoria principale.
• La velocità di memoria non è così elevata come la maggior parte della gente si aspetta. QPI è nella regione di 25 GB / sec.

Alcuni di questi motivi sono stati trattati in Quando utilizzare TINYINT su INT? che potresti trovare utile. Suggerirei anche di seguire le buffonate di @ThomasKejser ( blog ) del team SQLCAT, in quanto tendono ad essere all'avanguardia nel promuovere le prestazioni del database. Il recente post su The Effect of CPU Caches and Memory Access Patterns e la presentazione SQLBits su Relational Modeling for Extreme DW Scale sono buoni esempi.

Secondo me, si tratta ancora di bilanciare tra normalizzare e de-normalizzare . Concordo pienamente sul fatto che i framework ORM sono semplicemente approcci per fare le cose, ma non credo che siano questi framework a causare la tendenza alla de-normalizzazione .

è ancora quel dibattito che si desidera efficienza nel tempo o efficienza nello spazio. Al momento della teoria dei database relazionali, l'archiviazione su disco è costosa, le persone ovviamente non vogliono spendere così tanti soldi per questo, ecco perché a quel tempo i database relazionali sono quelli che resistono alle avversità

Oggi le cose sono abbastanza diverse, lo spazio di archiviazione è molto economico. Quindi ovviamente possiamo tollerare una maggiore ridondanza rispetto ai vecchi tempi, questo è anche PERCHÉ è apparso l'approccio BIG_TABLE. per cercare una maggiore efficienza nel tempo, è necessario sacrificare l'efficienza dello spazio.

Ma anche l'approccio Big-table non è la fine della storia, è ancora l'equilibrio tra tempo e spazio, in termini di dati del volume PB da gestire, alcuni sviluppatori hanno anche iniziato a cercare l'equilibrio per l'efficienza spaziale, ecco perché lì sono lavori eseguiti per normalizzare alcuni dati in strutture simili a BIG-TABLE.

In una parola, l'approccio alla normalizzazione non è definitivamente morto, ma rispetto ai vecchi tempi è sicuramente trascurato.

CJ Date risponde alla tua domanda qui: il video di normalizzazione (prelim) è gratuito.

http://shop.oreilly.com/product/0636920025900.do

La risposta breve: la normalizzazione è il modo matematicamente corretto di fare le cose. Se non si normalizza correttamente, il modello di dati è semplicemente errato.