Tracabilité des modifications des données.

Bonjour à tous,

Je bosse actuellement sur un problème concernant la traçabilité des modifications des données dans la base de données.
Le fonctionnel est simple : avoir une table (peut être plusieurs) contenant approximativement les champs: valeur avant, valeur après, qui, quand, type de l'élément modifié, identifiant de l'élément modifié, ....

Après recherche sur le web, j'ai vu que le l'utilisation des triggers pouvaient s'appliquer à peu près pour cette problématique.

Je voudrais savoir s'il n'est pas possible de le faire par programmation c#, d’une manière assez simple, relativement générique et pas trop couteuse en temps de développement.

Quelque chose qui ressemblerait peut être, à conserver les anciennes valeurs et comparer l’ensemble des valeurs. N’étant pas très expérimenté en c#, j’avoue ne pas savoir dans quel sens prendre le problème.

Merci d’avance pour votre aide.

Salut,

Il faudrait éventuellement que tu est la main sur ta couche d'accès aux données et que tu log toi même lors des transactions les modifications apportés.

Je l'ai fait il y'a longtemps en Oracle, avec des triggers...

Il faut arriver à bien voir la différence entre le gain qu'on en attends et le cout que ca represente pour des grosses volumétries...


Pour le coup des logs, ca *peut* etre une bonne idée, mais de mon expérience, si tu as une quantité de données non négligeable, les logs vont vite devenir peu aisés à manipuler (à moins de loger en base de données, mais tu perds de la précision)

La règle qu'on a adopté pour ce genre de choses, c'est que les logs permettent de conserver des informations liées au fonctionnement de l'appli (entrée ou sortie d'une fonction, erreurs...), alors que ce que tu veux, c'est plus une fonctionnalité métier

Citation:

---

Envoyé par DarkHerumor

Salut,

Il faudrait éventuellement que tu est la main sur ta couche d'accès aux données et que tu log toi même lors des transactions les modifications apportés.

---

Merci pour ta réponse,

Je peux avoir facilement la main sur la couche d'accès aux données.
Si j'ai bien compris ce que tu me proposes de faire, c'est avant chaque "update" de faire un "select" de l'objet à mettre à jour et de comparer champ par champ pour pouvoir faire des insert dans ma table d'historique. J'ai bien compris?

Citation:

---

Envoyé par pvialatte

Je l'ai fait il y'a longtemps en Oracle, avec des triggers...

Il faut arriver à bien voir la différence entre le gain qu'on en attends et le cout que ca represente pour des grosses volumétries...


Pour le coup des logs, ca *peut* etre une bonne idée, mais de mon expérience, si tu as une quantité de données non négligeable, les logs vont vite devenir peu aisés à manipuler (à moins de loger en base de données, mais tu perds de la précision)

La règle qu'on a adopté pour ce genre de choses, c'est que les logs permettent de conserver des informations liées au fonctionnement de l'appli (entrée ou sortie d'une fonction, erreurs...), alors que ce que tu veux, c'est plus une fonctionnalité métier

---

OK merci,
Au risque d'être hors charte:

• Peut on passer des paramètres à un trigger pour connaître le login utilisateur par exemple?

• Peut on retrouver les attributs modifiées et seulement ceux-ci avec un trigger?

Je me disais à l'origine que par programmation se serait peut être plus simple à mettre en oeuvre et à maintenir. En pratique, je ne sais pas quoi penser!!

Merci.

Je pense que la solution des triggers sera au final la meilleure comme l'explique pvialatte.

Tu ne peux (de mémoire) pas passer proprement dit de paramètres à un trigger. Cependant un trigger sur une action de Update, aura accès aux anciennes valeurs (avant Update) et aux nouvelles (après update).

Par contre si ta table n'a pas de lien direct avec le login de ton Utilisateur, je t'avoue que je ne sais pas trop comment récupérer celui-ci. A part peu-être via une table supplémentaire enregistrant simplement [Login|Action|Table], et en descendant cette table, mais le tout dans une transaction (sinon tu risque d'avoir une désynchronisation entre action / dernier login).
Mais là, attention aux perfs :?

Merci,

Ton idée d'une table suplémentaire est bonne, mais effectivement les perfs risquent de la sentir passer.
Je ne suis toujours pas trop sur de moi sur ce sujet, et reste donc ouvrir à différentes propositions/amélioration des choses intéressants que vous m'avez proposées.

Les triggers pourraientt ils vraiment n'enregistrer que les champs modifiés assez facilement ou ressemblerons t'ils plutôt à une usine à gaz.:cry: