Discussion :

[jeffupds]

Personne ne peut me renseigner pour mon historique ?
Je vais effectivement avoir un grand nombre d'enregistrements mais le stockage n'est pas un soucis, je peux utiliser des techniques d'archivages.

Par ailleurs, je cherche un moyen de surveiller ma base MySQL et de garder un historique.

C'est à dire que lorsque n'importe quel champ est modifié dans la base, je veux garder et pouvoir retrouver :
- l'ancienne valeur
- la date de modif
- l'utilisateur qui l'a modifié
Il me faut donc les clefs du champ modifié, etc...

Si quelqu'un pouvait me trouver le moyen de faire ça, je lui en serais très reconnaissant... Je ne sais pas si un outil d'administration ou de monitoring de la base permet de faire ça (je suis sous Linux).
Pourriez-vous me renseigner ?

Merci d'avance.

[Sujet déplacé par Maximilian]

[Maximil ian]

Bonjour,

Tu peux faire ça en activant le log de requêtes (option --log=nom_fichier au démarrage du serveur).

Je crois que MySQL Administrator permet de consulter ce log depuis son interface (à vérifier).

[jeffupds]

j'ai activé les logs mais la seule chose enregistrée dedans c'est les requetes et encore pas toutes. Pas les utilisateurs, et surtout pas les anciennes valeurs des champs.

[Maximil ian]

Le query log te signale les connexions (user et id), et journalise toutes les requêtes avec l'id de connexion pour chacune.

En effet les anciennes valeurs ne sont pas répertoriées (j'avais mal lu ton premier message ). Il existe peut-être des outils pour le faire (je n'en connais pas) ou sinon c'est quelque chose que tu peux implémenter toi-même. Par contre pour une base très sollicitée, ça risque de gréver les performances...

[pcaboche]

c'est quelque chose que tu peux implémenter toi-même

C'est un truc auquel j'avais pensé, mais j'ai trouvé ta première réponse plus pertinente.

J'imaginais un système avec:
- des tables pour enregistrer l'historique des valeurs (ex: si tu as une table "matable", tu aurais une table "matable_hist" avec des infos telles que la date de modif, la vaeur, etc...)
- des triggers qui se déclanchent à chaque changement de "matable" pour mettre à jour "matable_hist"

Avantages:
- tu as un contrôle total de ce que tu veux monitorer
- ça fait exactement ce que tu veux
- tu peux désactiver le monitoring en désactivant les triggers

Inconvénients:
- triggers = MySQL 5
- à implémenter soi-même (même si après, tu peux dire: "vous avez vu? c'est moi qui l'ai fait !")
- ça nuit aux performances (comme le disait Maximilian)
- pour retrouver le nom de l'utilisateur ayant fait la modif, c'est pas évident

[jeffupds]

Merci pour vos réponses.

Je suis déjà sous MySQL5. J'avais bien entendu pensé aux triggers et à faire une table historique, le problème c'est que j'ai énormément de table et de champs alors la mise en place de tous les triggers va être très longue.
Je sais aussi que ça va diminuer les performances de la base mais je n'ai pas le choix, c'est une contrainte légale dans le secteur pour lequel je développe en ce moment (médecine).

Donc pour le moment j'apprends à utiliser les triggers mais si quelqu'un a une meilleure solution (plus simple à mettre en place), je suis prenneur !

Merci encore.