Table d'audit et type 2 Modification lente de la cote

Question

Dans SQL Server 2008+, nous souhaitons activer le suivi des modifications historiques dans une table "Customers" dans une base de données opérationnelle.

C'est une nouvelle table et notre application contrôle toutes les écritures dans la base de données, donc nous n'avons pas besoin de hacks maléfiques comme des triggers. Au lieu de cela, nous allons construire le suivi des modifications dans notre couche d'objet métier, mais nous devons trouver le bon schéma de base de données à utiliser.

Le nombre de lignes sera inférieur à 100 000 et le nombre de changements par enregistrement sera en moyenne de 1,5 par an.

Il y a au moins deux façons que nous avons cherché à modéliser ceci:

1. Comme une table Type 2 Slowly Changing Dimension appelée CustomersHistory, avec des colonnes pour EffectiveStartDate, EffectiveEndDate (mis à NULL pour la version actuelle du client), et auditer des colonnes comme ChangeReason et ChangedByUsername. Ensuite, nous construirions une vue Customers sur cette table qui est filtrée en EffectiveEndDate=NULL. La plupart des parties de notre application interrogeraient en utilisant cette vue, et seules les parties qui doivent être sensibles à l'historique interrogeraient la table sous-jacente. Pour les performances, nous pourrions matérialiser la vue et/ou ajouter un index filtré sur EffectiveEndDate = NULL.

2. Avec une table d'audit séparée. Chaque modification apportée à un enregistrement Customer écrit une fois dans la table Customer et à nouveau dans la table de vérification CustomerHistory.

D'après un examen rapide des questions StackOverflow, # 2 semble être beaucoup plus populaire. Mais est-ce parce que la plupart des applications DB doivent faire face à des écrivains hérités et voyous? Étant donné que nous partons d'une liste vierge, quels sont les avantages et les inconvénients de l'une ou l'autre approche? Lequel recommanderiez-vous?

Answer 1

En général, le problème avec SCD Type-II est que, si le nombre moyen de changements dans les valeurs des attributs est très élevé, vous finissez par avoir une table de dimension très grosse. Cette table de dimension croissante jointe à une énorme table de faits ralentit graduellement les performances de la requête. C'est comme un empoisonnement lent. Au départ, vous ne voyez pas l'impact. Quand vous le réalisez, il est trop tard!

Maintenant, je comprends que vous allez créer une vue matérialisée séparée avec EffectiveEndDate = NULL et qui sera utilisée dans la plupart de vos jointures. De plus pour vous, le volume de données est relativement faible (100 000). Avec des changements moyens de seulement 1,5 par an, je ne pense pas que le volume de données/performance de la requête etc. sera votre problème dans un proche avenir. En d'autres termes, votre table est vraiment lentement changement de dimension (par opposition à un rapidly changing dimension - où votre option # 2 est un meilleur ajustement). Dans votre cas, je préférerai l'option # 1.