Tableau d'historique de la base de données / Tableau de suivi

13

Actuellement, je veux structurer un tableau de suivi / historique comme ceci:

PrimaryKey - ID
OtherTableId - fk
fieldName - nom du champ son suivi
OldValue
Nouvelle valeur
Nom d'utilisateur
CreateDateTime

Donc, fondamentalement, je veux avoir une table qui suivra l'historique d'une autre table, stockera le nom de la colonne du champ modifié avec la nouvelle et l'ancienne valeur. Ma question est: quelqu'un peut-il percer des trous dans tout cela? De plus, quelle est la manière la plus simple de s'assurer que seul un nom de colonne des tables dont le suivi est entré dans la colonne fieldName? Actuellement, mes options sont d'avoir une énumération dans le service que je construis, ou de créer une autre table d'état et de faire de fieldName un fk. De meilleures idées?

Modifier l' objectif: il n'y a actuellement que 2 champs que nous souhaitons suivre. Un champ sera affiché sur une page Web pour afficher l'historique, l'autre champ ne sera accessible que par un département et ils auront accès à une vue de la base de données qu'ils pourraient interroger. Ils interrogeraient uniquement ce champ pour obtenir des informations sur qui a changé le champ et sur quoi. C'est la raison pour laquelle nous voulions le placer où un champ de base de données définit la colonne de table plutôt que d'avoir une copie exacte de l'historique des enregistrements de table. Nous voulons seulement que deux champs soient suivis avec les possibilités d'ajouter ou de supprimer des champs à l'avenir.

Merci!

database sql tracking

— user76982
source

Savez-vous à l'avance combien de tableaux vous allez suivre?

— Kofi Sarfo

Cette table ne suivra qu'une autre table, jusqu'à présent, nous suivons uniquement cette table.

— user76982

Cette approche pourrait donc être exagérée. Pire encore, il ne sera pas facile d'interroger cette table avec celle qui est surveillée ensemble pour recréer les données en direct à un moment donné, si la recréation d'un instantané avait une valeur quelconque.

— Kofi Sarfo

1

D'un autre côté, la requête pour voir quelles colonnes changent le plus souvent sera plus facile en utilisant l'approche que vous avez proposée.

— Kofi Sarfo du

Vous pouvez rechercher sur dba.stackexchange.com ; des questions similaires y ont été posées et certaines pourraient avoir des réponses que vous pouvez utiliser.

— FrustratedWithFormsDesigner

8

Piquer des trous: que se passe-t-il si le schéma de la base de données est modifié au même moment plus tard, et qu'un nom de colonne change, ou que la colonne est supprimée complètement? Beaucoup de système de base de données le permettent. Qu'adviendra-t-il alors de votre "fieldName"?

Pour l'intégrité des données: vous devez vous assurer que chaque opération de mise à jour ou de suppression mettra à jour votre table de suivi. Pour ce faire, les déclencheurs appellent une procédure stockée. Vous devez vous assurer que seules ces procédures stockées ont un accès en écriture à votre table de suivi, afin que personne d'autre ne puisse écrire de mauvaises valeurs.

Si vous pouvez vivre avec une solution spécifique au fournisseur db: la plupart des systèmes db ont des tables système où les informations de schéma (noms de table, identifiants de table, noms de colonne, etc.) sont stockées. Vous pouvez vérifier s'il est possible de définir une référence de clé étrangère à une telle table système. Cela permettrait de remplacer le nom du champ par un ID de champ si la base de données prend en charge quelque chose comme ça.

En fait, si vous devez suivre des lignes entières du tableau spécifique, y compris toutes les colonnes (et pas seulement un petit sous-ensemble des colonnes), vous devriez considérer la suggestion de @ sarfeast. Lisez cet article sur les inconvénients des modèles de paires nom-valeur.

— Doc Brown
source

8

L'implémentation de l'audit des modifications (suivi de l'historique) la plus réussie que j'ai vue est moins générique et beaucoup plus simple. Il s'agit de créer une table de journal des modifications pour chaque table que vous souhaitez surveiller, en conservant des noms de colonne et des types de données identiques (avec une colonne supplémentaire pour l'horodatage).

L'objectif final, c'est-à-dire ce que vous aimeriez faire avec les données auditées vous aidera à évaluer dans quelle mesure chaque approche pourrait convenir.

— Kofi Sarfo
source

Bonjour Sarfeast, j'ai ajouté l'objectif final que je veux atteindre. Désolé de ne pas avoir inclus cela pour commencer.

— user76982

Cette approche a ses inconvénients. Lisez ici: database-programmer.blogspot.co.uk/2008/07/history-tables.html

— Tuukka Haapaniemi

7

En bref: vous devez définir le mécanisme Audit Trail pour les tables dont vous souhaitez suivre la modification de valeur.

Table de suivi d'audit unique :

Créez une table pour enregistrer le nom de la table, le nom du champ et les anciennes et nouvelles versions des données. Pour cette méthode, il est habituel de consigner à la fois les anciennes et les nouvelles versions des données et uniquement les champs qui ont changé. Pour implémenter cela dans les déclencheurs, il est nécessaire qu'il y ait une clé primaire sur la table ou que seules les lignes soient mises à jour.

Voici un bon article avec des scripts sur la façon d'y parvenir - Création de pistes d'audit

Autres références utiles à regarder:

— Yusubov
source

Le deuxième lien est mauvais maintenant.

— Jeremy Harris

@cillosis, merci de l'avoir remarqué. Il est mis à jour maintenant :)

— Yusubov

3

Vous voudrez peut-être consulter la documentation du projet NHibernate Envers pour des idées.

Fondamentalement, vous avez une table de révision où vous pouvez ajouter des données supplémentaires comme un horodatage ou un utilisateur. Ensuite, chaque table que vous suivez obtient une table d'audit supplémentaire avec toutes les colonnes dupliquées, un fk à la table de révision et le type de révision (ajouter, modifier, supprimer). AFAIK, vous ne voudriez pas que vos tables d'audit aient un FK réel à la vraie table car cela empêcherait les suppressions.

— dotjoe
source