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

Question

Je dois créer une table de base de données pour stocker différents journaux de modifications / audits. (quand 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 l'événement)
• utilisateur qui l'a déclenché
• nom de l'événement
• description de l'événement
• horodatage de l'événement

Est-ce que je manque quelque chose ici? Bien entendu, 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 ce genre de choses, car c’est une complication pour mon besoin).

Answer 1

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. L’audit 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, pour pouvoir répondre rapidement à ces questions (en utilisant SQL), nous avons fini par avoir deux colonnes supplémentaires dans la table d'audit

object type (or table name)
object ID

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

Bien sûr, 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é!

Answer 2

Il y a plusieurs autres choses que vous voudrez peut-être auditer, telles que les noms de table / colonne, l'ordinateur / l'application à partir de laquelle une mise à jour a été faite, etc. "

Maintenant, cela dépend du niveau de détail de l'audit dont vous avez réellement besoin.

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 procédé à la rétroingénierie de l’outil tiers, basé sur des déclencheurs, ApexSQL. Audit pour 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)

• Stockez des données en dehors de la base de données principale, comme suggéré par Robert

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

• Planifiez le stockage du nom de l'hôte / de l'application. Cela peut s'avérer très utile pour le suivi des activités suspectes

Answer 3

Nous enregistrons également les anciennes et les nouvelles valeurs et leur colonne, ainsi que la clé primaire de la table en cours d’audit 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é, il vaut mieux être déjà préparé.

Answer 4

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 les suivantes:

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 souhaitez 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.

Answer 5

Ce que nous avons dans notre tableau: -

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 seule colonne de clé de substitution, donc cela fonctionne bien.

Answer 6

Il existe plusieurs façons de procéder. Ma manière préférée est:

1. Ajoutez un champ mod_user à votre table source (celle que vous souhaitez consigner).

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

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

Vous avez maintenant une liste de tous les changements et de leur auteur.

Answer 7

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 insè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 / "Hands on Data Architect" " doit impliquer dans la destitution d’un tel système en fonction des besoins. Il s’agit en général de problèmes trop graves à confier aux développeurs pour obtenir une solution.

Answer 8

Selon le principe de séparation:

1. Les tables de données d'audit doivent être séparées 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.

Answer 9

En retard pour la fête, mais je recommande vivement le projet AutoAudit .
C'est 100% gratuit et open source. Il est écrit par les MVPs SQL Paul Nielsen et John Sigouin. Il 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, des SP de maintenance et les déclencheurs nécessaires à l’audit. A partir de là, il suffit de choisir les tables que vous souhaitez vérifier et avec quels détails.