Est-ce une bonne conception pour une table d'audit avec des tonnes d'enregistrements?

Question

J'ai une table qui suit les données d'inventaire par chaque pièce individuelle. Ceci est une version simplifiée de la table (certains champs non-clés sont exclus):

UniqueID, 
ProductSKU, 
SerialNumber, 
OnHandStatus, 
Cost, 
DateTimeStamp 

Chaque fois que quelque chose arrive à un morceau donné, un nouveau record d'audit est créé. Par exemple, la première fois que mon produit ABC est ajouté à l'inventaire je reçois un dossier comme celui-ci:

1, ABC, 555, OnHand, $500, 01/01/2009 @ 02:05:22 

Si le coût de ABC le numéro de série 555 changements, je reçois un nouveau record:

2, ABC, 555, OnHand, $600, 01/02/2009 @ 04:25:11 

Si la pièce est vendue, je reçois un nouveau record:

3, ABC, 555, Sold, $600, 02/01/2009 @ 5:55:55 

Si une nouvelle pièce d'ABC est apporté, je reçois ce disque:

4, ABC, 888, OnHand, $600, 02/05/2009 @ 9:01:01 

Je dois être en mesure d'obtenir la valeur d'inventaire en main pour un ensemble donné de produits à tout moment aussi vite que possible. En utilisant mon exemple ci-dessus, si je voulais obtenir ma valeur d'inventaire pour le produit ABC à partir du 01/02/2009, je devrais sélectionner, pour chaque combinaison unique Produit/Numéro de série, le plus récent enregistrementavant au 01/03/2009 avec le statut "OnHand" et ensuite additionner les coûts. (Je ne suis pas sûr à 100% de ce à quoi ressemblerait cette déclaration select à ce stade, mais je vais expérimenter un peu).

Mes questions: est-ce une bonne structure pour le type de tableau d'audit que je décris? Autrement dit, se prête-t-il à des requêtes rapides si elles sont indexées de manière appropriée? (J'essaie d'imaginer ce qui se passera lorsque cette table atteindra des millions de lignes.)

Dois-je décomposer les enregistrements historiques en une table distincte et ne laisser que l'enregistrement le plus récent pour chaque combinaison ProductID/SerialNumber dans le " table active?

Tous les commentaires/suggestions/commentaires/liens sont appréciés.

Merci!

Answer 1

Vous allez vous simplifier la vie en disposant d'un tableau de données en direct distinct de vos données d'audit, c'est une très bonne idée. Pour un fonctionnement quotidien normal, vous ne devriez même pas avoir besoin de regarder les données d'audit, donc le fait d'avoir la même table que vos données en direct va juste causer des maux de tête. Le moyen le plus simple de gérer ceci serait de mettre un trigger sur la table live de sorte que chaque fois qu'un enregistrement est inséré/supprimé/mis à jour, il insère automagiquement un nouvel enregistrement dans la table d'audit.

modifier: expansion sur Kevin's réflexions à ce sujet, j'imagine que quel que soit le numéro de série, toutes les pièces qui partagent la même SKU auraient le même prix? Si tel est le cas, avoir une table de prix séparée est certainement une bonne idée aussi.

Answer 2

Toutes les valeurs ne sont pas mises à jour en même temps, pourquoi reproduire toutes les informations statiques?Je pense que vous devriez avoir des tables différentes pour le numéro de série, le statut et le coût. Chacune de ces tables aura également l'ID du produit et la date de mise à jour. De cette façon, vous pouvez également facilement déterminer quelle partie du produit a changé. Avant, vous pouviez comparer tous les champs du produit avec tous les champs du produit qui avaient été sauvegardés juste avant le premier.

Answer 3

Vous devrez séparer vos données d'audit. Conserver les données actuelles ensemble avec les données d'audit aura un impact sur les performances au fil du temps.

L'implémentation la plus simple consisterait à créer une base de données distincte avec le même schéma que la production. Ajoutez un horodatage à chaque table dans la base de données d'audit. Créez une clé primaire composite à partir de la clé primaire de production et du nouveau tampon datetime.

Configurez un déclencheur sur la base de données de production afin que chaque insertion/mise à jour dans la base de données de production déclenche une insertion dans la base de données d'audit. Les valeurs insérées dans la base de données d'audit seront les valeurs nouvellement insérées. N'utilisez la base de données d'audit qu'à des fins de rapport d'audit. Alternativement, vous pouvez également envisager de créer un data-mart qui serait chargé de suivre les changements au fil du temps. (Mais cela prend beaucoup de temps et d'efforts)

Answer 4

D'abord, un peu de définition (non defs clinique, juste ma propre de séparation des idées nomenclature):

========= =

Table initiale: La table au quotidien à laquelle vous ajoutez et récupérez.

Table d'audit: Table contenant plusieurs versions d'un enregistrement dans sa table initiale associée.

==========

Si l'utilisation commerciale d'une table de vérification doit être en mesure de dire quel enregistrement ressemblait à tout moment, je dirais que ce devrait être construit de manière identique à la table initiale (plus l'ajout d'un ID d'audit unique).

S'il est plus important de savoir ce qu'est une valeur de champ à un moment donné (par opposition à l'enregistrement dans son ensemble), essayez l'approche plus succincte table-champ-valeur-date. S'il vous plaît noter qu'il faut beaucoup plus de travail pour reconstruire l'ensemble du disque avec cette approche, alors oubliez-le si la récupération de tout dossier peut devenir nécessaire. Dans l'ensemble, je pense que dans la plupart des cas, les performances rapides utilisant la version la plus récente d'un enregistrement sont plus importantes que les performances utilisant les données d'audit. Par conséquent, je suggère de créer la table d'audit de manière identique à la table initiale (plus la clé de substitution autonumérotée), et de déclencher une insertion des mêmes données dans la table d'audit quand elle est ajoutée à la table initiale. Cela maintient le nombre d'enregistrements relativement statique dans la table initiale et les performances ne se dégradent pas au fil du temps.