e Dimensione di modifica di tipo 2

Question

In SQL Server 2008+, vorremmo abilitare il tracciamento delle modifiche cronologiche a una tabella "Clienti" in un database operativo.

È un nuovo tavolo e la nostra app controlla tutti gli scritti sul database, quindi non abbiamo bisogno di hack maligni come i trigger. Costruiremo invece il rilevamento delle modifiche nel nostro livello di oggetto aziendale, ma è necessario individuare lo schema del database corretto da utilizzare.

Il numero di righe sarà inferiore a 100.000 e il numero di modifiche per record sarà pari a 1,5 l'anno.

Ci sono almeno due modi che abbiamo preso in esame modellare questo:

1. Come un tavolo Type 2 Slowly Changing Dimension chiamato CustomersHistory, con colonne per EffectiveStartDate, EffectiveEndDate (impostato NULL per la versione corrente del cliente) e auditing di colonne come ChangeReason e ChangedByUsername. Quindi creiamo una vista Customers su quel tavolo che viene filtrata su EffectiveEndDate=NULL. La maggior parte delle parti della nostra app interrogherebbe usando quella vista, e solo le parti che devono essere a conoscenza della storia interrogheranno la tabella sottostante. Per prestazioni, potremmo materializzare la vista e/o aggiungere un indice filtrato su EffectiveEndDate = NULL.

2. Con una tabella di controllo separata. Ogni modifica a un record Customer scrive una volta sulla tabella Customer e di nuovo su una tabella di controllo CustomerHistory.

Da una rapida rassegna delle domande StackOverflow, il numero 2 sembra essere molto più popolare. Ma questo è dovuto al fatto che la maggior parte delle app DB ha a che fare con scrittori legacy e canaglia?

Dato che stiamo iniziando da una lavagna vuota, quali sono i pro e i contro di entrambi gli approcci? Quale raccomanderesti?

Answer 1

In generale, il problema con SCD Tipo II è, se il numero medio di modifiche nei valori degli attributi è molto elevato, si finisce con una tabella delle dimensioni molto grossa. Questa tabella delle dimensioni crescente unita a un'enorme tabella dei fatti rallenta gradualmente le prestazioni della query. È come avvelenare lentamente .. Inizialmente non si vede l'impatto. Quando lo realizzi, è troppo tardi!

Ora capisco che creerai una vista materializzata separata con EffectiveEndDate = NULL e che verrà utilizzata nella maggior parte dei tuoi join. Inoltre, per te, il volume dei dati è relativamente basso (100.000). Con variazioni medie di solo 1,5 all'anno, non penso che il volume di dati/prestazioni di query, ecc saranno il vostro problema nel prossimo futuro.

In altre parole, la vostra tavola è veramente una dimensione modificabile lentamente (in contrapposizione ad un rapidly changing dimension - in cui la vostra opzione # 2 è una misura migliore). Nel tuo caso, preferirò l'opzione n. 1.