Je ne suis pas sûr qu'il y ait une "meilleure approche", il y a tellement de variables à prendre en considération, y compris à quel point vous êtes sur la voie du développement.
Ayant utilisé à la fois des solutions d'audit basées sur du code et des déclencheurs de base de données, j'ai énuméré quelques commentaires ci-dessous ; J'espère que vous voyez où vous en êtes maintenant (en termes de développement) et que cela pourrait affecter ces problèmes :
- Si vous avez besoin de mapper l'utilisateur qui a modifié les données (ce que vous faites normalement), les déclencheurs db devront obtenir ces informations d'une manière ou d'une autre. Pas impossible, mais plus de travail et plusieurs façons d'aborder cela (utilisateur de la base de données exécutant une requête, colonne d'utilisateur commune dans chaque table, etc.)
- Si vous utilisez des déclencheurs db et que vous comptez sur le nombre de lignes affectées renvoyées par les requêtes, vos déclencheurs d'audit doivent désactiver cette option ou modifier votre code existant pour en tenir compte.
- Les déclencheurs de base de données IMHO offrent plus de sécurité et offrent un chemin plus facile vers l'automatisation de l'audit, mais ils ne sont pas infaillibles, car toute personne disposant d'un accès approprié peut désactiver les déclencheurs, modifier les données, puis les réactiver. En d'autres termes, assurez-vous que vos droits d'accès à la sécurité de la base de données sont stricts.
- Avoir une seule table pour l'historique n'est pas une mauvaise solution, même si vous aurez plus de travail à faire (et de données à stocker) si vous auditez l'historique de plusieurs tables, en particulier lorsqu'il s'agit de reconstruire la piste d'audit. Vous devez également tenir compte des problèmes de verrouillage si de nombreuses tables essaient d'écrire dans une table d'audit.
- Avoir une table d'historique d'audit pour chaque table est une autre option. Vous avez juste besoin que chaque colonne de la table d'audit soit nullable, ainsi que de stocker la date et l'heure de l'action (insérer/mettre à jour/supprimer) et l'utilisateur associé à l'action.
- Si vous optez pour l'option de table unique, à moins que vous n'ayez beaucoup de temps à consacrer à cela, n'ayez pas trop envie d'essayer d'auditer uniquement les mises à jour ou les suppressions, même s'il peut être tentant d'éviter les insertions (car la plupart les applications le font plus souvent que les mises à jour ou les suppressions), la reconstruction de l'historique d'audit demande un peu de travail.
- Si vos serveurs ou vos données couvrent plusieurs fuseaux horaires, envisagez d'utiliser un type de date/heure approprié pour pouvoir stocker et reconstruire la chronologie, c'est-à-dire stocker la date de l'événement d'audit en UTC et inclure le décalage de fuseau horaire.
- Ces tables d'audit peuvent devenir volumineuses. Ayez donc une stratégie si elles commencent à affecter les performances. Les options incluent le partitionnement de table sur différents disques, l'archivage, etc. Pensez-y essentiellement maintenant et non quand cela devient un problème :)
