Stockage des champs auditables par entité

Question

Je pense qu'il est une bonne pratique pour capturer des champs auditables pour suivre ce qui est arrivé à une entité particulière (disons CreatedBy, creationDate, ModifiedBy, ModifiedDate)

1. Je suppose si un objet est jamais modifié il est logique juste de capturer les champs auditables suivants pour un événement SNMPv3 (disons createdBy, creationDate)

2. Je suppose qu'un objet est modifiable après sa création par plusieurs personnes, par exemple un profil utilisateur peut être modifié par auto ou admin alors il serait logique de capturer tous les attributs ci-dessus (dis CreateBy, cr eationDate, ModifiedBy, ModifiedDate)

3. En supposant une histoire de piste d'audit par entité n'est pas nécessaire, serait-il judicieux de stocker tous les attributs auditables dans l'entité elle-même

4. Serait-il judicieux de déléguer l'audit à un Framework tiers (disons JBoss Envers - http://www.jboss.org/envers) pour les cas d'utilisation ci-dessus.

5. En supposant qu'une entité (par exemple un ordre d'achat) est créée et gérée par l'utilisateur X, et que l'utilisateur Y apporte quelques améliorations à la commande d'achat ci-dessus. Qui devrait être marqué comme le propriétaire de cette entité (est-ce le créateur ou le modificateur)? creationDate dans ce cas pourrait ne pas être du tout pertinent, il serait donc logique de suivre ce domaine ici.

Note: La couche de persistance sous-jacente est basée sur JPA, Hibernate 3.3.x

Answer 1

(1) et (2) semble raisonnable bien qu'il ne serait probablement pas de mal à traiter toutes les entités du même plutôt que compliquer avec des entités créer-seulement et créer/modifier. (3) Le stockage sur l'entité est le plus simple, mais je serais tenté d'avoir une seule table ou table par entité juste pour les données d'audit. Cela vous donnerait de la flexibilité si vous vouliez stocker plusieurs modifications, c'est-à-dire l'historique complet. Et peut-être une légère amélioration des performances lors de l'interrogation de l'entité principale.

(4) Envers semble intéressant et facile, mais il semble stocker un historique complet et vous avez indiqué que ce n'était pas nécessaire, donc il pourrait être trop.

(5) Je dirais que le créateur est toujours la personne (ou processus) qui a provoqué l'insertion initiale et modificateur est la dernière personne/processus qui a provoqué une mise à jour. Si vous souhaitez prendre des décisions commerciales concernant le propriétaire, traitez-le comme un champ distinct plutôt que comme faisant partie de votre solution d'audit.