Développer un système d'historique des actions sur une BDD

[mr_go]

Bonjour,

je ne m'étais jamais penché sur le problème du suivi des mises à jour de tables par un internaute (Exemple : Le 14 Juillet 2006, Yvon a modifié son adresse -> 12 Rue des Lilas devient 25 rue des Tulipes), pour la simple et bonne raison que je n'en avais pas l'utilité.

Néanmoins, un besoin se fait sentir à ce niveau, et j'aurais souhaité connaître vos méthodes permettant de gérer simplement ce type de process.

Quelle est pour vous la meilleure méthode ?

Exemple : créer une table parrallèle à la table client reprenant les mêmes champs avec data différents (lourd au niveau data), créer une table "historique" (relativement lourd au niveau gestion)...

Si un framework existe (j'en doute) en PHP, je suis évidememnt preneur...

 

[Zim']

le mieux est de créer une nouvelle table, et de doubler tous tes updates enclenchés par le visiteur avec un insert... en nommant chaque action, que tu place dans un champ de type ENUM, ou chaque éléments (nom, prénom etc), ou voir meme les deux, et un troisieme (ou deuxieme champ), avec l'élément updaté, et enfin un autre avec l'id du pseudo du membre par exemple...

bref, c'est assez chiant a faire, mais disons qu'il n'y a rien de très "lourd"

 

[blman]

Si j'ai bien compris, tu peux faire une table "journal" qui enregistre ce qui se passe (ajout-modification-suppression). Si tu lie (verbe "lier") chaque ligne avec ta table "user", tu peux faire plusieurs types de journaux :
- un journal global
- un journal par user

Outre le fait d'avoir un historique, ça permet aussi de tirer des stats sur ce qui se passe sur ton site (action les plus utilisées, fréquence d'utilisation, etc...).

En e-commerce, on use et abuse de ce type de journaux (à titre d'exemple, une recherche rapide m'a permis de tomber sur cette page : http://www.officemovies.com/french/form ... ables.html )

 

[Bacteries]

mr_go> Tu as quoi comme BDD? Tu as les trigger pour ça sinon (Oracle, Postgre, ... le font) Pas MySQL (enfin pas la 4, le 5 non plus je crois).

Sinon si tu es en MySQL tu as peut être une classe qui permet ton requêtage (pour éviter d'être dépendant de ta BDD) et y'a peut être quelque chose à voir de ce coté là. Pour chaque insert ou update tu réalise une seconde requête. Le problème ça va être d'enregistrer autre chose que la requête pour rendre le truc lisible facilement.

 

[mr_go]

Si tu lie (verbe "lier")

... oui sinon "tu lis" (verbe "lire")

Outre le fait d'avoir un historique, ça permet aussi de tirer des stats sur ce qui se passe sur ton site.

Oui c'est tout à fait le principe, être informé d'une modification d'adresse ou de numéro de fax par exemple.

 

[mr_go]

mr_go> Tu as quoi comme BDD? Tu as les trigger pour ça sinon (Oracle, Postgre, ... le font) Pas MySQL (enfin pas la 4, le 5 non plus je crois).

Ah, oui, indépendance de plateforme si possible (je développe via PEAR MDB2).

Edit : il me semble avoir vu que les triggers étaient d'actualité sur la dernière version MySQL, en alpha si ma mémoire est bonne.

 

[Sir Dipp]

Depuis MySQL 5.0 les trigger (procédure) sont en effet opérationnelles, mais là encore peu d'hébergeurs (voir aucun) propose cette version à tord puisque très intéressante

A+

 

[mr_go]

Ill est vrai que cela m'aurait simplifié fortement la tâche...

Je vais me pencher sur la proposition de Zim qui me paraît être la plus adaptée, même si les procédures de récupération d'historique sont du coup un peu plus complexes à réaliser.

Merci pour vos propositions.