Pour un projet, je travaille sur, on m'a demandé de créer une piste d'audit de tous les changements apportés aux enregistrements. C'est la première fois que j'ai dû créer une piste d'audit, alors j'ai fait beaucoup de recherches sur le sujet.
L'application sera développée dans PHP / MSSQL et sera faible trafic.
De ma lecture, j'ai à peu près décidé d'avoir une table d'audit et d'utiliser des déclencheurs pour enregistrer les changements dans la table.
Les deux exigences d'affichage dans l'application sont les suivantes:
Pouvoir voir un journal de toutes les modifications apportées à un champ (je sais à peu près comment faire cela)
Pouvoir voir, lors de la visualisation d'un enregistrement dans l'application, un indicateur à côté de tout champ de l'enregistrement qui a déjà été changé (et éventuellement d'autres informations comme la date du dernier changement).
L'article n ° 2 est celui qui me donne actuellement de chagrin. Sans faire une requête séparée pour chaque champ (ou une très longue requête imbriquée qui prendra des âges à exécuter), quelqu'un a-t-il des suggestions pour une manière optimale de le faire? (J'ai pensé à ajouter un champ supplémentaire "modifié" pour chaque champ de la table, qui agira comme indicateur booléen si le champ a déjà été édité, mais cela semble être beaucoup de frais généraux.
3 Réponses :
Je traiterais les informations d'audit séparément des informations actuelles du domaine autant que possible.
Si votre base de données ne prend pas en charge les déclencheurs, vous utilisez peut-être une sorte de type de persistance ou de base de données. Ce serait également un bon endroit pour mettre ce type de logique, comme à nouveau, vous minimisez toutes les dépendances entre le code d'application normal em> et le code d'audit. P> J'essaierais de laisser le code Responsable de l'affichage du formulaire également être responsable de la présentation de données d'audit sur le terrain. Cela provoquera des frais généraux de requête, mais c'est le coût d'affichage de cette couche supplémentaire d'informations. Peut-être que vous pouvez minimiser la surcharge de la base de données en ajoutant des métadonnées aux informations d'audit permettant une récupération facile. P> Certaines applications de grande entreprise que je maintiennent utilise à peu près la structure suivante: p> champs: p> - une table de champ de changement correspondant à un champ modifié. p> champs: P>
'1', 'Title', 'The Hitchhiker's Guide to the Gaxaly', 'The Hitchhiker's Guide to the Galaxy'
'1', 'Author', 'Duglas Adasm', 'Douglas Adams'
Pour «récupération facile» de laquelle des champs sont modifiés, je pourrais peut-être créer un déclencheur qui stocké l'enregistrement initial sur la création à la fois dans la table principale et dans une table des «originaux» séparée? Ensuite, pour l'affichage, je pourrais simplement récupérer l'enregistrement des deux tables («principaux» et «originaux») et les comparer au code pour signaler les champs appropriés?
C'est possible, mais vous auriez alors deux tables pour chaque chose que vous souhaitez stocker et que vous ne pouvez voir qu'un certain nombre de champs ont changé depuis la création de l'enregistrement. La solution mentionnée dans ma réponse vous permet de créer une piste d'audit détaillée qui peut indiquer quels champs ont changé au fil du temps et quelles valeurs ont ces champs. En d'autres termes, vous construisez une histoire. De plus, vous n'avez pas besoin de créer deux tables pour tout, de vos tables «principales» et de votre en-tête de sentier d'audit et de votre table d'objet
Logique. Je ne me suis probablement pas fabriqué sur mon premier commentaire. Je voulais dire qu'en plus de la méthode que vous avez suggérée ci-dessus (que je suis d'accord avec), créez également une table séparée pour stocker l'enregistrement d'origine. Cela permettrait, je pense, la récupération beaucoup plus facile d'une liste simple de champs modifiés (pour les champs de marquage comme modifiés), que d'essayer de récupérer si de la piste d'audit. J'utiliserais toujours le sentier pour afficher les détails de tous les changements.
Ok, c'est un sens de la vue de la performance et de la facilité de développement!
comme une exigence générale signalant le champ modifié "sent" légèrement étrange. Si les enregistrements sont vécus depuis longtemps et sont sujets à changement au fil du temps, tous les champs auront finalement tendance à être signalés. Par conséquent, je me demande comment tout utilisateur pourrait donner un sens à un simple ensemble d'indicateurs par champ.
Cette ligne de pensée me fait penser que les données que vous stockez doivent être, comme vous l'avez décrite, un vrai sentier d'audit avec tous les changements enregistrés et le premier défi réel est de décider comment les informations doivent être présentées à l'utilisateur.
Je pense que votre idée de préparer une sorte de données agrégattheudittrail est susceptible d'être très utile. La question serait un drapeau unique par rapport? Si l'accès principal de l'utilisateur est à travers la liste, il suffit-il de mettre en surbrillance les enregistrements modifiés pour l'exploration ultérieure. Ou une date de dernière modification de la valeur de l'enregistrement, de sorte que seules les enregistrements récemment modifiés sont mis en évidence - tous revenus à ce que les besoins réels de l'utilisateur sont. J'ai du mal à imaginer que les enregistrements changés il y a 3 ans sont aussi intervérants que ceux qui ont changé la semaine dernière.
Alors, lorsque nous arrivons à l'exploration à un seul enregistrement. Encore une fois, un drapeau simple par champ ne semble pas utile (bien que votre domaine, vos besoins). Si c'est le cas, alors votre idée de résumé va bien. Je suppose que c'est qu'une séquence de modifications apportées à un champ, et la séquence de modifications générales à l'enregistrement, sont beaucoup plus intéressantes. Employé avait une hausse salariale, département du déménagement des employés, employé a été promu = trois événements d'affaires distincts ou un?
Si quelque chose de plus qu'un simple drapeau est nécessaire, je suppose que vous devez simplement renvoyer la piste d'audit totale (ou récente) pour le compte rendu et laisser l'interface utilisateur de déterminer comment présenter cela.
Donc, ma pensée initiale: une sorte de maintien de la maintenance d'un enregistrement de résumé ressemble à une bonne idée. Si nécessaire maintenues dans des threads de fond ou des travaux de lot. Nous déisgnions que pour être utiles pour être utiles sans aller à la piste d'audit complète à chaque fois. Ensuite, pour des analyses détaillées, nous autorisons tout ou partie de la piste à extraire.
Une autre explication de la demande est probablement en ordre. Les enregistrements, bien qu'ils soient vraisemblablement archivés, ne sont «actifs» que pour un an. C'est une application de stocker des objectifs pour l'année, qui sont entrés au début de l'année après leur approbation par la direction. Les propriétaires de but peuvent ensuite entrer et modifier le statut de n'importe quel objectif, mais s'ils apportent des modifications aux données d'objectifs initiaux, il doit être "marqué" d'une manière ou d'une autre. Fondamentalement, il s'agit d'un système de gestion de projet simplifié;)
Personnellement, je ferais le suivi simple, et le rapport funky.
Chaque fois qu'un utilisateur insère un enregistrement, vous établissez une insertion dans la table d'audit pour ce tableau P>
'I','May 3 2009','BLT','person005','John','Smith','Marketing' 'U','May 4 2009','BLT','person005','John','Smith','Accounting'