Si vous avez l'édition d'entreprise 10g, vous devriez consulter l'audit à grain fin d'Oracle. C'est certainement mieux que de rouler le vôtre.
Mais si vous avez une version inférieure ou pour une raison quelconque FGA n'est pas à votre goût, voici comment procéder. L'essentiel est :créez une table d'audit distincte pour chaque table d'application .
Je sais que ce n'est pas ce que vous voulez entendre car cela ne correspond pas à la structure de table que vous avez décrite ci-dessus. Mais stocker une ligne avec les valeurs OLD et NEW pour chaque colonne affectée par une mise à jour est une très mauvaise idée :
- Il ne s'adapte pas (une seule mise à jour touchant dix colonnes génère dix insertions)
- Qu'en est-il lorsque vous insérez un enregistrement ?
- C'est une vraie galère d'assembler l'état d'un enregistrement à un moment donné
Ainsi, ayez une table d'audit pour chaque table d'application, avec une structure identique. Cela signifie inclure CHANGED_TIMESTAMP et CHANGED_USER dans la table d'application, mais ce n'est pas une mauvaise chose.
Enfin, et vous savez où cela mène, ayez un déclencheur sur chaque table qui insère un enregistrement entier avec uniquement les valeurs :NEW dans la table d'audit. Le déclencheur doit se déclencher sur INSERT et UPDATE. Cela donne l'historique complet, il est assez facile de différencier deux versions de l'enregistrement. Pour un DELETE, vous insérerez un enregistrement d'audit avec uniquement la clé primaire renseignée et toutes les autres colonnes vides.
Votre objection sera que vous avez trop de tables et trop de colonnes pour implémenter tous ces objets. Mais il est assez simple de générer la table et de déclencher des instructions DDL à partir du dictionnaire de données (user_tables, user_tab_columns).
