Comment puis-je utiliser une piste de vérification pour afficher les champs ont déjà été édités?

Question

Pour un projet sur lequel je travaille, on m'a demandé de créer une piste de vérification de toutes les modifications qui ont été apportées aux enregistrements. Ceci est la première fois que je l'ai dû créer une piste d'audit, donc je fais beaucoup de recherches sur le sujet.

L'application sera développée en PHP / MSSQL et sera faible trafic.

De ma lecture, j'ai à peu près décidé d'avoir une table de vérification et de l'utilisation des déclencheurs pour enregistrer les changements dans la table.

Les deux exigences pour l'affichage dans l'application sont les suivantes:

1. Être capable de voir un journal de toutes les modifications apportées à un champ (je sais à peu près comment faire)

2. Être capable de voir, lors de la visualisation d'un enregistrement dans l'application, un indicateur à côté d'un champ dans l'enregistrement qui n'a jamais été changé (et peut-être d'autres informations comme la date de la dernière modification).

Point # 2 est celui qui est actuellement me donne la douleur. Sans faire une requête distincte pour chaque champ (ou une très longue requête imbriquée qui prendra les âges à exécuter), quelqu'un at-il des suggestions pour une meilleure façon de le faire? (Je l'ai pensé à ajouter un champ « ModifiedFlag » supplémentaire pour chaque champ de la table, qui agira comme indicateur booléen si le champ n'a jamais été modifié, mais qui semble comme beaucoup de frais généraux.

Answer 1

Je traiterais les informations d'audit séparément des informations de domaine réel, autant que possible.

Exigence n ° 1: Je pense que vous allez créer des tables de vérification supplémentaires pour enregistrer les modifications. suggestion Eric est un bon, créant ainsi les informations d'audit en utilisant des déclencheurs dans la base de données SQL. De cette façon, votre application doit pas être au courant de la logique d'audit.

Si votre base de données ne prend pas en charge les déclencheurs, alors peut-être que vous utilisez une sorte de persistance ou d'une couche de base de données. Ce serait également un bon endroit pour mettre ce genre de logique, comme nouveau vous réduisez au minimum toutes les dépendances entre normale code d'application et le code de vérification.

Exigence n ° 2: En ce qui concerne les indicateurs montrant: Je ne crée pas des champs booléens dans la table qui stocke le réel. (Cela causerait toutes sortes de dépendances existent entre votre normale code d'application et votre piste de vérification code.)

Je voudrais essayer de laisser le code responsable de l'affichage de la forme soit également chargé de montrer des données d'audit sur le terrain. Cela entraînera les frais généraux d'interrogation, mais qui est le coût pour l'affichage de cette couche d'information supplémentaire. Peut-être que vous pouvez réduire les frais généraux de base de données en ajoutant des métadonnées aux informations d'audit qui permet de les retrouver facilement.

Certaines grande application Enterprisy que je maintiens utilise à peu près la structure suivante:

• Une table d'en-tête de changement correspondant à un changement d'un enregistrement dans une table.

Les champs:

changeId, changeTable, changedPrimaryKey, userName, dateTime

-. Une table de champ de changement correspondant à un champ qui est modifié

Les champs:

changeId, changeField, oldValue, NewValue

Contenu de l'échantillon:

Modifier en-tête:

'1', 'BooksTable', '1852860138', 'AdamsD', '2009-07-01 15:30'

Modifier l'objet:

'1', 'Title', 'The Hitchhiker's Guide to the Gaxaly', 'The Hitchhiker's Guide to the Galaxy'
'1', 'Author', 'Duglas Adasm', 'Douglas Adams'

Cette structure permet à la fois faciliter la visualisation des pistes de vérification, ainsi que la récupération facile pour montrer les indicateurs souhaités. Une requête (jointure interne dans l'en-tête et produits tableau) serait suffisant pour récupérer toutes les informations à afficher dans une seule forme. (Ou même une table lorsque vous avez une liste de numéros d'identification montré)

Answer 2

En tant que condition générale de signalisation des champs a « odeurs » un peu bizarre. Si les dossiers sont à vie longue et changer au fil du temps, puis à terme tous les champs auront tendance à obtenir ainsi signalé. Par conséquent, je me demande comment un utilisateur pourrait avoir un sens d'un simple ensemble d'indicateurs par champ.

Cette ligne de pensée me fait soupçonner que les données que vous stockez doit être, comme vous l'avez décrit, une vraie piste de vérification avec tous les changements enregistrés, et le premier vrai défi est de décider comment l'information doit être présentée à l'utilisateur.

Je pense que votre idée de préparer une sorte de données aggregateOfTheAuditTrail est susceptible d'être très utile. La question serait un seul drapeau par enregistrement suffisant? Si l'accès principal de l'utilisateur est par la liste alors peut-être il est juste assez pour mettre en évidence les enregistrements modifiés pour percer plus tard vers le bas. Ou une date de la dernière modification de la valeur d'enregistrement, de sorte que les enregistrements modifiés récemment sont mis en évidence - tous à ce que les besoins réels de l'utilisateur sont. Je trouve qu'il est difficile d'imaginer que les dossiers ont changé il y a 3 ans sont aussi interessant que ceux a changé la semaine dernière.

Ensuite, lorsque nous arrivons à l'exercice à un seul enregistrement. Encore une fois un drapeau simple par champ ne semble pas utile (si votre domaine, vos besoins). S'il est, votre idée sommaire est très bien. Je suppose qu'une séquence de changements à un champ, et la séquence des changements globaux à l'enregistrement, sont beaucoup plus intéressantes. Employé avait augmentation de salaire, l'employé emménagea, employé a été promu = trois événements d'affaires séparés ou un?

Si quelque chose de plus qu'un simple drapeau est nécessaire, alors je pense que vous avez juste besoin de retourner l'ensemble (ou récent) piste de vérification pour le dossier et laisser la figure de l'interface utilisateur comment présenter cela.

Alors, ma pensée initiale: Une sorte de matériel d'entretien d'un enregistrement sommaire sonne comme une bonne idée. Si nécessaire maintenu dans les discussions de fond ou des travaux par lots. Nous Deisgn que pour être utile-entreprise sans passer à la piste de vérification complète à chaque fois. Ensuite, pour des analyses détaillées que nous autorisons tout ou partie de la piste à récupérer.

Answer 3

Personnellement, je fais simple le suivi et le reporting funky.

Chaque fois qu'un utilisateur insère un enregistrement, vous faites une insertion dans la table de vérification pour cette table

'I', 'Date', 'User', 'Data column1','Data Column2', etc.

C'est la structure en supposant les tables ne changera pas au fil du temps (re. Le montant de DataColumns)

Pour les mises à jour, il suffit d'insérer

'U', 'Date', 'User', 'Data column1', etc

Insérer ce que l'utilisateur vient d'entrer dans une mise à jour.

Ensuite, après l'insertion et la mise à jour, vous aurez les éléments suivants

'I','May 3 2009','BLT','person005','John','Smith','Marketing'
'U','May 4 2009','BLT','person005','John','Smith','Accounting'

Ensuite, il est juste un rapport facile de montrer que la personne unique enregistrement « person005 » a eu un insert et une mise à jour, où leur service a été mis à jour.

En raison de la faible utilisation du système, ayant une insertion simple sur le changement alors un processus de reporting plus complexe ne va pas affecter les performances. Ce style fonctionne toujours avec les systèmes de trafic plus élevés, comme la charge supplémentaire sur une modification est minime, alors que plus la charge de travail d'intensité de faire rapport les changements ne se fait pas aussi souvent une mise à jour, de sorte que le système ne tombe pas.