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

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

Il tuo database analitico (magazzino) dovrebbe 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 / dirigenti senior di fare molti join per una semplice analisi, beh, potreste essere licenziati.

Design Agile Data Warehouse è un buon libro

Vedi i miei consigli per il data warehouse sporchi e veloci qui

Capisco, perché qualcuno vuole evitare di scrivere un join per each select.

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

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

Le risposte che sono già state pubblicizzate pubblicamente coprono il "come evitare la duplicazione" (usando le viste) ma non il perché. In pratica mostrano che la duplicazione delle colonne è la soluzione sbagliata al problema di semplificare la scrittura delle query. Ma la domanda "perché non duplicare alcuna colonna casuale solo per il gusto di farlo?" sta ancora

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

If something can go wrong, it will.

In questo caso, si suppone che il contenuto di ogni campo di riga di una colonna duplicata sia 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. Potresti pensare di aver preso tutte le precauzioni possibili per assicurarti che non differiscano, ma la legge di Murphy afferma che poiché possono differire, saranno differenti. E lo scompiglio sarà .

Come esempio di come ciò possa accadere, considera semplicemente il fatto che le colonne duplicate non vengono riempite dalla magia; qualcuno deve effettivamente scrivere un codice che memorizzi valori in essi ogni volta che vengono create righe nella tabella originale e qualcuno deve scrivere un codice che continui ad aggiornarli ogni volta che gli originali vengono modificati. Mettendo da parte il fatto che questo sta aggiungendo un onere eccessivo al codice che immette i dati nel database (e che è, per definizione, molto più cruciale di qualsiasi codice che interroga semplicemente il database), qualcuno, da qualche parte, in determinate circostanze, potrebbe dimenticare per eseguire questa duplicazione. Quindi, i valori saranno diversi. Oppure potrebbero ricordarsi di eseguire la duplicazione, ma non all'interno di una transazione, quindi potrebbe, in determinate rare condizioni di errore, essere omessa. Ma non avevo davvero bisogno di sprecare il mio tempo scrivendo questi esempi, e non avevi davvero bisogno di sprecare il tuo tempo a leggerli: la bellezza della Legge di Murphy è che ci salva dal dover trovare esempi di come qualcosa possa andare storto caso per caso: se può andare male, lo farà.

Pensare in termini di compromessi piuttosto che buoni / cattivi sarà più produttivo. Scambiano i vantaggi della normalizzazione (in particolare la coerenza) per i vantaggi nell'usabilità delle query.

A un estremo, il database diventerebbe inutile se i dati diventassero 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.

Che cosa puoi fare per ridurre i rischi e i costi?

• Crea uno strumento per il controllo della coerenza ed eseguilo regolarmente.
• Instrada l'accesso in scrittura tramite software che aggiorna i dati replicati in modo coerente.
• Aggiungi viste o crea strumenti di query che eseguono automaticamente i join in modo che gli uomini d'affari possano pensare in termini di informazioni piuttosto che gli interni del database.

Penso che l'argomento più strong per la normalizzazione dei dati per gli analisti aziendali sia che promuove l'integrità dei dati. Se i dati della chiave sono memorizzati in un'unica posizione (una colonna, in una tabella), è molto meno probabile che i dati vengano corretti da aggiornamenti non corretti. Penso che probabilmente si interesserebbero dell'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 di query leggermente più difficile sarà probabilmente preferibile al potenziale danneggiamento dei dati.

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

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

Esci.

Onestamente, puoi passare mesi a discutere sulla normalizzazione, la coerenza e la lotta contro i bug pazzi causati dalla pigrizia pura e poi uscire.

Oppure puoi risparmiare tempo e frustrazione e uscire subito.

I bravi programmatori sono persone molto pigre. Comprendono le esigenze del cliente e della gestione. Ma, soprattutto, capiscono che risolvere i problemi bene, usando soluzioni ben progettate e ben implementate li salva personalmente ENORME quantità di lavoro, sforzo e, soprattutto, agonia e stress.

Quindi lavoreresti molto meglio in un luogo che comprende e apprezza la buona ingegneria.

Buona fortuna.

Ripensamento: Forse quello di cui hanno bisogno sono gli strumenti BI / OLAP ... link