Hum, j'y pensais aussi.
- Avoir une table par table pour conserver les révisions ne serait pas vraiment un problème pour moi personnellement, mais bon.
- Le nom d'utilisateur peut être conservé avec des variables définies par l'utilisateur, je crois, (après le démarrage d'une session, lancez quelque chose comme
SET @user='someone', et utilisez-le. - Tant qu'il y a des déclencheurs après INSERT, UPDATE et DELETE, obtenir les valeurs précédentes/suivantes est une simple requête, je ne stockerai que les valeurs OLD.
En bref, pour une table avec des colonnes (a,b,c), je créerais une table avec des colonnes (user_id,modtime,a,b,c).
Inconvénients majeurs :
- les mises à jour par lots sont lente (choisissez donc vos tableaux pour conserver soigneusement les révisions)
- duplication de données deluxe, vous devrez/je devrai disposer d'un espace de stockage suffisant
- les données "liées" ne déclenchent pas de révision (c'est-à-dire la modification d'un
group_memberstable ne modifie pas vraiment ungroupstable, alors que vous voudrez peut-être garder cela comme un point dans le temps pour lesgroupsplutôt que de plonger dansgroup_membersmodifications.
Dans l'ensemble, cela me semble une bonne affaire, mais comme je l'ai rarement vu en pratique, il doit être des raisons impérieuses pour lesquelles c'est mauvais, donc j'attendrai ces réponses.
