Chaque fois que j'ai besoin de concevoir une nouvelle base de données, je passe un certain temps à réfléchir à la façon dont je dois configurer le schéma de base de données pour conserver un journal d'audit des modifications.
Certaines questions ont déjà été posées ici à ce sujet, mais je ne suis pas d'accord pour dire qu'il existe une seule meilleure approche pour tous les scénarios:
- Conception de base de données pour les révisions
- Meilleure conception pour une table de base de données d'audit du journal des modifications
- Idées sur la conception de bases de données pour capturer des pistes d'audit
Je suis également tombé sur cet article intéressant sur la gestion d'un journal des modifications de la base de données qui tente de répertorier les avantages et les inconvénients de chaque approche. Il est très bien écrit et contient des informations intéressantes, mais cela a rendu mes décisions encore plus difficiles.
Ma question est la suivante: y a-t-il une référence que je peux utiliser, peut-être un livre ou quelque chose comme un arbre de décision auquel je peux me référer pour décider dans quelle direction dois-je aller en fonction de certaines variables d'entrée, comme:
- La maturité du schéma de base de données
- Comment les journaux seront interrogés
- La probabilité qu'il soit nécessaire de recréer des enregistrements
- Le plus important: les performances d'écriture ou de lecture
- Nature des valeurs enregistrées (chaîne, nombres, blobs)
- Espace de stockage disponible
Les approches que je connais sont:
1. Ajoutez des colonnes pour la date et l'utilisateur créés et modifiés
Exemple de tableau:
- id
- valeur_1
- valeur_2
- valeur_3
- created_date
- date modifiée
- créé par
- modifié par
Principaux inconvénients: Nous perdons l'historique des modifications. Impossible de revenir en arrière après la validation.
2. Insérez uniquement des tableaux
- id
- valeur_1
- valeur_2
- valeur_3
- de
- à
- supprimé (booléen)
- utilisateur
Principaux inconvénients: comment garder les clés étrangères à jour? Grand espace nécessaire
3. Créez une table d'historique séparée pour chaque table
Exemple de table d'historique:
- id
- valeur_1
- valeur_2
- valeur_3
- valeur_4
- utilisateur
- supprimé (booléen)
- horodatage
Principaux inconvénients: Nécessite de dupliquer toutes les tables vérifiées. Si le schéma change, il sera également nécessaire de migrer tous les journaux.
4. Créer une table d'historique consolidée pour toutes les tables
Exemple de table d'historique:
- nom de la table
- champ
- utilisateur
- nouvelle valeur
- supprimé (booléen)
- horodatage
Principaux inconvénients: Serai-je capable de recréer facilement les enregistrements (restauration) si nécessaire? La colonne new_value doit être une chaîne énorme pour pouvoir prendre en charge tous les types de colonnes différents.