web-dev-qa-db-fra.com

Meilleur design pour une table de base de données de journal des modifications / d’audit?

J'ai besoin de créer une table de base de données pour stocker différents journaux de changements/audits (lorsque quelque chose a été ajouté, supprimé, modifié, etc.). Je n'ai pas besoin de stocker des informations particulièrement détaillées, alors je pensais à quelque chose comme:

  • id (pour événement)
  • utilisateur qui l'a déclenché
  • nom de l'événement
  • description de l'évenement
  • horodatage de l'événement

Est-ce que j'ai râté quelque chose? Évidemment, je peux continuer à améliorer la conception, même si je n’envisage pas de la rendre compliquée (il est hors de question de créer d’autres tables pour des types d’événements ou des choses de ce type, car c’est une complication pour mon besoin).

databasedatabase-designaudit
103
rcphq

Dans le projet sur lequel je travaille, le journal d'audit a également démarré à partir d'une conception très minimaliste, comme celle que vous avez décrite:

event ID
event date/time
event type
user ID
description

L'idée était la même: garder les choses simples.

Cependant, il est vite devenu évident que ce design minimaliste n'était pas suffisant. La vérification typique se résumait à des questions comme celle-ci:

Who the heck created/updated/deleted a record 
with ID=X in the table Foo and when?

Donc, afin de pouvoir répondre rapidement à de telles questions (avec SQL), nous avons fini par avoir deux colonnes supplémentaires dans la table d'audit

object type (or table name)
object ID

C'est alors que la conception de notre journal d'audit s'est vraiment stabilisée (depuis quelques années maintenant).

Bien entendu, la dernière "amélioration" ne fonctionnerait que pour les tables ayant des clés de substitution. Mais devinez quoi? Toutes nos tables qui méritent d'être auditées ont une telle clé!

63
Yarik

Vous voudrez peut-être également auditer d'autres éléments, tels que les noms de table/colonne, l'ordinateur/l'application à partir duquel une mise à jour a été effectuée, etc.

Maintenant, cela dépend de la précision de l'audit dont vous avez réellement besoin et à quel niveau.

Nous avons commencé à mettre en place notre propre solution d'audit à base de déclencheurs. Nous souhaitions tout contrôler et disposer d'une option de récupération. Cela s’est avéré trop complexe, nous avons donc décidé de procéder à la rétro-ingénierie de l’outil tiers basé sur des déclencheurs ApexSQL Audit afin de créer notre propre solution personnalisée.

Conseils:

  • Inclure les valeurs avant/après

  • Incluez 3-4 colonnes pour stocker la clé primaire (s'il s'agit d'une clé composite)

  • Stocker des données en dehors de la base de données principale comme l'a déjà suggéré Robert

  • Consacrez un temps raisonnable à la préparation des rapports, en particulier ceux dont vous pourriez avoir besoin pour récupérer

  • Planifiez le stockage du nom de l'hôte/de l'application - cela peut s'avérer très utile pour suivre les activités suspectes

23
Kenneth Hampton

Nous enregistrons également les anciennes et les nouvelles valeurs, ainsi que la colonne dont elles proviennent, ainsi que la clé primaire de la table auditée dans une table de détail d'audit. Vous pensez à quoi vous avez besoin de la table d'audit? Vous voulez non seulement savoir qui a effectué un changement et quand, mais lorsqu'un mauvais changement se produit, vous souhaitez un moyen rapide de rétablir les données.

Pendant la conception, vous devez écrire le code pour récupérer les données. Lorsque vous avez besoin de récupérer, il est généralement pressé, mieux vaut déjà être prêt.

19
HLGEM

Il y a beaucoup de réponses intéressantes ici et dans des questions similaires. Les seules choses que je peux ajouter par expérience personnelle sont:

  1. Placez votre table d'audit dans une autre base de données. Idéalement, vous souhaitez séparer les données d'origine. Si vous devez restaurer votre base de données, vous ne voulez pas vraiment restaurer le journal d'audit.

  2. Dénormaliser autant que raisonnablement possible. Vous voulez que la table ait le moins de dépendances possible avec les données d'origine. La table d'audit doit être simple et rapide pour récupérer les données. Aucune jointure ou recherche sophistiquée sur d'autres tables pour accéder aux données.

8
Robert4Real

Ce que nous avons dans notre table: -

Primary Key
Event type (e.g. "UPDATED", "APPROVED")
Description ("Frisbar was added to blong")
User Id
User Id of second authoriser
Amount
Date/time
Generic Id
Table Name

L'identifiant générique pointe sur une ligne de la table qui a été mise à jour et le nom de la table est le nom de cette table sous forme de chaîne. Pas une bonne conception de base de données, mais très utilisable. Toutes nos tables ont une colonne de clé de substitution unique, donc cela fonctionne bien.

4
WW.

Il y a plusieurs façons de le faire. Ma manière préférée est:

  1. Ajouter un mod_user dans votre table source (celle que vous souhaitez consigner).

  2. Créez une table de journal contenant les champs que vous souhaitez consigner, plus un log_datetime et seq_num champ. seq_num est la clé primaire.

  3. Créez un déclencheur sur la table source qui insère l'enregistrement en cours dans la table de journal chaque fois qu'un champ surveillé est modifié.

Maintenant, vous avez un enregistrement de chaque changement et qui l'a fait.

4
JosephStyons

En général, l’audit personnalisé (création de plusieurs tables) est une mauvaise option. Les déclencheurs de base de données/table peuvent être désactivés pour ignorer certaines activités du journal. Les tables d'audit personnalisées peuvent être altérées. Des exceptions peuvent avoir lieu qui réduiront l'application. Sans parler des difficultés à concevoir une solution robuste. Jusqu'ici, je vois un cas très simple dans cette discussion. Vous avez besoin d'une séparation complète de la base de données actuelle et de tout utilisateur privilégié (DBA, développeurs). Tous les SGBDR traditionnels offrent des fonctionnalités d'audit que même les administrateurs de bases de données ne sont pas en mesure de désactiver, de manipuler en secret. Par conséquent, la capacité d'audit fournie par le fournisseur de SGBDR doit être la première option. Une autre option serait un lecteur de journaux de transactions tiers ou un lecteur de journaux personnalisé qui transfère des informations décomposées dans un système de messagerie qui aboutit à certaines formes de magasin de données d'audit ou de gestionnaire d'événements en temps réel. En résumé: Architecte de solution/"Architecte de données pratique" doit participer à la désinstallation d'un tel système en fonction des besoins. Il est généralement trop grave de laisser le soin à un développeur de trouver une solution.

3
Joel Mamedov

Selon le principe de séparation:

  1. Les tableaux de données d'audit doivent être séparés de la base de données principale. Les bases de données d'audit pouvant contenir de nombreuses données historiques, il est logique, du point de vue de l'utilisation de la mémoire, de les séparer.

  2. N'utilisez pas de déclencheurs pour auditer toute la base de données, car vous allez vous retrouver avec un fouillis de bases de données différentes à prendre en charge. Vous devrez en écrire un pour DB2, SQLServer, Mysql, etc.

1
Bhagat007

En retard à la fête, mais je recommande vivement le projet AutoAudit .
Il est 100% gratuit et open source. Il est écrit par les MVPs SQL Paul Nielsen et John Sigouin. C'est très stable et est actuellement sur la version 3.30.

Simple à installer. Il suffit de lancer le SP qu’ils fournissent. Il créera un schéma d’audit, quelques SP de maintenance et les déclencheurs nécessaires à l’audit. A partir de là, il suffit de choisir les tables que vous souhaitez auditer et avec quel détail.

0
Troy Witthoeft