Discussion :

[Soccent74]

Bonjour à tous,

dans le cadre de mon projet en entreprise, je souhaite historiciser plusieurs tables de ma base de données.

Après de nombreuse recherche (notamment sur ce site), ils sembleraient que j'ai besoin de faire une historisation en mode ligne. C'est à dire, enregistrer toute la ligne dans une autre table lors d'un UPDATE par exemple.
Néanmoins, l'objet que je souhaite historiciser se répartie en plusieurs table. L'utilisateur final a accès à la base de données via une interface web. La séparation des tables est invisible pour lui, et nous sommes obligé de maintenir l'objet en plusieurs tables.

Je manque de connaissance sur les Triggers et je souhaite un conseil sur mon choix : Trigger ou PHP pour le chargement de la base de données d'historisation.

Lors de la modification, le PHP connait les anciennes valeurs de mon objet, et les nouvelles. Je dois mettre à jours plusieurs table d'un seul coup. Vaut-il mieux privilégier la construction de toute les requêtes en PHP (modif dans la table d'historisation, puis modif dans la table en production) ?

OU

Je modifie la table de production. Et je mets en place des triggers sur celle-ci pour faire la copie des anciennes valeurs dans la table d'historisation ?

Dans l'attentes de vos réponses.
Et merci !

Soccent

[SQLpro]

Toute solution applicative fonctionne de manière itérative et non ensembliste comme le fait le SGBDR.
En cas de pluralité de ligne dans la mise à jour, votre système via PHP ne récupérerait les valeurs que d'une seule ligne... Laquelle ? Mystère !

De plus, si vous voulez faire ceci côté applicatif, alors vous devez gérer impérativement une transaction afin que le système ne tombe pas en panne entre la mise a jour fonctionnelle et l'insertion des lignes d'historique....

Ce n'est pas pour rien que les déclencheurs ont été inventé (en 1986 par Sybase !)

A +Bref,

[Soccent74]

Je rajoute ces informations.

Les utilisateurs modifie mon objet via un formulaire HTML. Je mets à jours ma base de données via PHP.
C'est pour ça que je demandais ce qui était le mieux. Il me paraissait beaucoup plus simple de construire deux petites requête plutôt qu'un TRIGGER.

Merci de ta réponse,
SQLpro tu es partout.

Bonne journée

[Soccent74]

Mon formulaire HTML contient environ 30 valeurs différentes que je dois updater dans 4 tables.

Pour ce faire j'ai opté pour une transaction qui va faire 4 requêtes update. Ceci sera fait en PHP.
Et en SQL, je mets en place les TRIGGERS nécessairent pour l'historisation de ma BDD.

Si personne n'a de remarque sous deux jours, j'indiquerai que ce TOPIC est résolu.

[alassanediakite]

Salut
J'opterais pour "le tout coté postgresql"...

• une vue qui constitue la base du formulaire
• un trigger INSTEAD OF INSERT UPDATE sur la vue qui s’occupera de la mise à jour des tables sous-jacentes et de l'insertion dans les tables d'historisation

@+

[Soccent74]

J'aime beaucoup cette idée.

Merci pour cette réponse !

[Soccent74]

Du coup je pense faire :

PHP : Transaction BEGIN
Requête INSERT dans la vue qui regroupe tous les attributs de mon objet.

SQL TRIGGER : INSTEAD OF INSERT UPDATE sur les 4 tables impactées

PHP : Contrôle que tout a fonctionné,
Transaction END

Voilà pour résumer dans les grandes lignes.

[SQLpro]

Du coup je pense faire :

PHP : Transaction BEGIN
Requête INSERT dans la vue qui regroupe tous les attributs de mon objet.

SQL TRIGGER : INSTEAD OF INSERT UPDATE sur les 4 tables impactées

PHP : Contrôle que tout a fonctionné,
Transaction END

Voilà pour résumer dans les grandes lignes.

Vous n'avez pas besoin d'une commande BEGIN TRANSACTION. En effet tout ordre SQL unique est une transaction à part entière et le déclencheur est exécuté de manière atomique au sein de la transaction de l'ordre SQL qui l'initie (INSERT, UPDATE ou DELETE)...

A +

[Soccent74]

Du coup je pars sur tout ceci.
Merci à vous !