Come posso argomentare in modo convincente contro la duplicazione delle colonne del database?


47

Ho iniziato a lavorare in una nuova organizzazione e uno dei modelli che ho visto nel database è la duplicazione dei campi per facilitare la scrittura di query per gli analisti aziendali. Stiamo usando Django e il suo ORM.

In un caso, manteniamo un oggetto MedicalRecordNumber con una stringa univoca che identifica un paziente in un determinato contesto. Abbiamo oggetti di registrazione che tracciano i pazienti e hanno associato MedicalRecordNumbers , ma invece di utilizzare una relazione di chiave esterna, duplicano la stringa in modo da evitare di scrivere un join ( non per motivi di prestazioni). Questo modello è comune in tutto il database.

Per me l'importanza di un modello di dati che è pulito è solo così posso pensarci bene. La complessità inutile è uno spreco del mio limitato tempo di elaborazione cognitiva. È un problema sistematico. Non sentirsi a proprio agio a scrivere join è una questione di abilità rettificabile. Non voglio necessariamente sostenere di tornare indietro e cambiare lo schema, ma mi piacerebbe essere in grado di articolare in modo convincente i problemi con questo tipo di duplicazione.


2
Cosa significa "non sentirsi a proprio agio a scrivere join"? Come lo spiegano?
scriptin,

9
Queste persone lavorano per te? Sei il loro supervisore? La maggior parte delle giustificazioni è disponibile qui: en.wikipedia.org/wiki/Database_normalization . Sì, devono migliorare nell'utilizzo dei join.
Robert Harvey,

1
Hai consultato la letteratura sul perché è desiderabile la normalizzazione?
Nathan Tuggy,

17
L'aggiunta di viste che uniscono internamente renderebbe altrettanto semplice la scrittura di query? Potresti suggerirli come alternativa.
CodesInChaos,

1
Hai comunicato questo (educatamente) con i tuoi coetanei e gli anziani? Quali sono le loro giustificazioni, quali considerazioni stanno facendo? Ci sono molte possibili ragioni per cui questa potrebbe essere una buona idea (anche se dici che "le prestazioni non sono la ragione", quali prove devi sostenere?). Prima di accusarli di essere troppo pigri e / o rigidi, hai considerato (e chiesto) i motivi che hanno per avere il design così com'è? Forse ci sono molte più letture che scritture (analytics heavy DB)? Rilevamento delle modifiche? Dati storici? Chiedi a tutti: qualcuno potrebbe sapere il vero motivo.
Luaan,

Risposte:


128

Il database operativo dovrebbe essere altamente normalizzato, per ridurre le anomalie .

Il database analitico (magazzino) deve essere altamente denormalizzato, per facilitare l'analisi.

Se non si dispone di un database analitico separato, è necessario creare alcune viste [materializzate] altamente denormalizzate.

Se dite ai vostri analisti / manager aziendali senior di fare molti join per una semplice analisi, potreste essere licenziati.

Agile Data Warehouse Design è un buon libro

Vedere i miei suggerimenti rapidi di data warehouse n' sporchi qui


9
Questa è la strada giusta da percorrere.
Nit

6
+1 Questo è esattamente lo scopo delle viste: consentire una vista denormalizzata su un database normalizzato.
Nzall,

4
Assolutamente corretto, ma penso che "ridurre le anomalie" dovrebbe essere enfatizzato maggiormente, poiché questa è la risposta principale alla domanda. L'anomalia (solo?) Più comune che vedrai con la duplicazione / denormalizzazione dei dati è che le colonne saranno in qualche modo popolate con dati contraddittori allo stesso tempo, lasciandoti senza modo di sapere quali dovrebbero essere i dati reali e no modo di determinare cosa è andato storto. Quest'ultimo può essere mitigato con un monitoraggio massiccio delle modifiche, ma questo non sarà economico o rapido da esaminare e trovare il problema. Più conveniente per evitare del tutto il problema.
jpmc26,

2
Un altro aspetto da considerare è che, anche supponendo che gli sviluppatori siano in grado di mantenere i dati (dubbi) corretti, diventa un enorme drenaggio delle loro risorse per garantire che ogni campo duplicato venga aggiornato quando richiesto per mantenere la coerenza.
Nate CK,

1
@Panzercrisis L'unico modo in cui una transazione è "implicita" è se hai un commit automatico in esecuzione alla fine della tua query. Questo non dovrebbe essere il caso di un database di produzione. In un'applicazione, le transazioni dovrebbero essere avviate automaticamente e un commit dovrebbe essere emesso separatamente dalla query. Questo è un piccolo investimento iniziale nell'applicazione, ma semplifica le modifiche al codice che comportano l'aggiunta di chiamate al database e riduce la quantità di informazioni a cui uno sviluppatore deve pensare (migliora la velocità degli sviluppatori, riduce gli errori degli sviluppatori). Questo tipo di design si adatta anche bene a cose come il pool di connessioni.
jpmc26,

57

Capisco, perché qualcuno vuole evitare di scrivere un join per ogni selezione.

Ma puoi creare una volta una vista con il join e usarla al posto della tabella non normalizzata.

Quindi unisci il vantaggio della normalizzazione con la comodità di una facile selezione.


12
Le viste sono i tuoi amici. Usali liberamente. E per prestazioni, potresti persino usare le viste materializzate se il tuo RDBMS le supporta.
VH-NZZ,

13

Le risposte che sono già state votate praticamente coprono il "come evitare la duplicazione" (usando le viste) ma non il perché. Fondamentalmente mostrano che la duplicazione delle colonne è la soluzione sbagliata al problema di rendere più semplice la scrittura di query. Ma la domanda "perché non duplicare una colonna casuale solo per diamine?" è ancora in piedi.

La risposta è "A causa della legge di Murphy". La legge di Murphy afferma che:

Se qualcosa può andare storto, lo farà.

In questo caso, il contenuto di ciascun campo di riga di una colonna duplicata dovrebbe essere identico al contenuto di ciascun campo di riga corrispondente della colonna originale. Ciò che può andare storto è che il contenuto di alcuni campi di riga può differire dagli originali, causando il caos. Si potrebbe pensare di aver preso tutte le precauzioni possibili per garantire che essi non differiscono, ma la legge di Murphy afferma che dal momento che possono differire, essi differiscono. E il caos ne conseguirà.

Come esempio di come ciò possa accadere, considera semplicemente il fatto che le colonne duplicate non si riempiono di magia; qualcuno deve effettivamente scrivere il codice che memorizza i valori al suo interno ogni volta che le righe vengono create nella tabella originale e qualcuno deve scrivere il codice che continua ad aggiornarli ogni volta che gli originali vengono modificati. Mettere da parte il fatto che ciò sta aggiungendo un onere eccessivo al codice che immette i dati nel database (e che, per definizione, è molto più cruciale di qualsiasi codice che richiede semplicemente il database), qualcuno, da qualche parte, in determinate circostanze, potrebbe dimenticare per eseguire questa duplicazione. Quindi, i valori differiranno. Oppure potrebbero ricordare di eseguire la duplicazione, ma non all'interno di una transazione, quindi potrebbe, in determinate rare condizioni di errore, essere omesso. Ma non avevo davvero bisogno di perdere tempo a scrivere questi esempi,se può andare storto, lo farà.


12

Pensarlo in termini di compromessi piuttosto che buono / cattivo sarà più produttivo. Stanno scambiando vantaggi della normalizzazione (in particolare coerenza) con vantaggi nell'usabilità delle query.

Ad un estremo, il database diventerebbe inutile se i dati diventassero gravemente incoerenti. All'altro estremo, il database sarebbe inutile se fosse troppo difficile per le persone che hanno bisogno di interrogarlo ogni giorno per ottenere risultati su cui poter contare.

Cosa puoi fare per ridurre i rischi e i costi?

  • Crea uno strumento di controllo della coerenza ed eseguilo regolarmente.
  • Instrada l'accesso in scrittura tramite software che aggiorna i dati replicati in modo coerente.
  • Aggiungi visualizzazioni o crea strumenti di query che eseguono automaticamente i join in modo che gli uomini d'affari possano pensare in termini di informazioni anziché all'interno del DB.

6

Penso che l'argomento più forte per la normalizzazione dei dati per gli analisti aziendali sia che promuove l'integrità dei dati. Se i tuoi dati chiave sono memorizzati in un solo posto (una colonna, in una tabella), è molto meno probabile che i dati vengano danneggiati da aggiornamenti errati. Penso che probabilmente avrebbero a cuore l'importanza dell'integrità dei dati, quindi questo potrebbe essere un buon modo per convincerli ad aggiornare i loro modi di interagire con il database.

Un metodo leggermente più difficile di interrogazione sarà probabilmente preferibile alla potenziale corruzione dei dati.


6
La sua gente sosterrà che sono abbastanza bravi da assicurarsi che tutti i dati vengano aggiornati correttamente (una premessa che contesto, se sono a disagio con i join). Forse un argomento migliore è che perdi la maggior parte dei vantaggi di ACID forniti da RDBMS, se eviti la normalizzazione.
Robert Harvey,

4
Probabilmente, ma è tutta una questione di rischio. Sono disposti ad accettare il rischio di corrompere il database perché semplifica l'interrogazione?
Oleksi,

1
Giocando qui l'avvocato del diavolo, un ovvio argomento contrario sarebbe che, se qualcuno rovinasse comunque un aggiornamento e corrompesse i dati, questo è un problema con o senza normalizzazione - e, almeno, avere una ridondanza nel database lo rende più probabile che qualcuno noterà la corruzione e potrebbe anche essere in grado di risolverlo in un secondo momento. (Certo, la denormalizzazione ad hoc non è certo lo schema di rilevamento degli errori più affidabile, ma il principio del controllo degli errori tramite ridondanza è valido: è così che funziona la contabilità a doppia entrata .)
Ilmari Karonen,

Oppure, per dirla in altri termini, c'è molto di più nell'integrità dei dati oltre alla semplice integrità relazionale. Con un database completamente normalizzato, puoi comunque mantenere la perfetta integrità relazionale anche se qualcuno sbaglia un aggiornamento, ma ciò non rende i dati erroneamente aggiornati meno spazzatura.
Ilmari Karonen,

0

Da aggiungere a ciò che gli altri ragazzi hanno suggerito sopra. Questo è un problema di governance dei dati. È necessario collaborare con le parti interessate: architetti di dati e amministratori di dati per sviluppare principi, politiche e convenzioni di denominazione dei dati.

Sii paziente e lavora metodicamente. Il cambiamento non avverrà durante la notte.


0

Smettere.

Onestamente, puoi passare mesi a discutere di normalizzazione, coerenza e combattere bug pazzi causati dalla pura pigrizia, e poi smettere.

Oppure puoi semplicemente risparmiare tempo, frustrazione e smettere ora.

I bravi programmatori sono persone molto pigre. Comprendono le esigenze del cliente e della gestione. Ma soprattutto comprendono che la risoluzione dei problemi, l'utilizzo di soluzioni ben progettate e ben implementate consente loro di risparmiare personalmente enormi quantità di lavoro, impegno e, soprattutto, agonia e stress.

Quindi sarebbe molto meglio lavorare in un posto che comprenda e apprezzi la buona ingegneria.

In bocca al lupo.


Ripensamento: forse ciò di cui hanno bisogno sono gli strumenti BI / OLAP ... http://en.wikipedia.org/wiki/Online_analytical_processing

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.