Bonjour,
 
Dans le cadre de test, j'aurais besoin d'être en mesure de lister l'exhaustivité des mises à jour effectuées sur une base de données après execution de certain traitement ou groupe de traitements.
 
En ayant un modèle de donnée de la forme :
 
   Table1
   Clef Champ11
   Data Champ 12
 
Apres déclaration des tables suivantes :
 
   Table1_insert
   Clef Champ11
   Data Champ 12
 
   Table1_update
   Clef Champ11
   Data Champ 12
 
   Table1_delete
   Clef Champ11
   Data Champ 12
 
Savez vous s'il est possible à l'aide de trigger de faire les opérations suivantes :
 
 - En cas d'insert dans Table1 :  
     de faire un insert dans Table1
     de faire un select dans Table1_delete et d'y supprimer l'instance si elle est trouvée et de faire un insert dans table1_update
       sinon de faire un insert dans Table1_insert
 
 - En cas d'update sur une instance de Table1 :  
     de faire l’update dans Table1.
     de faire un select dans Table1_insert et d'y updater l'instance si elle est trouvée,
       sinon, de faire un select dans table1_update d'y updater l'instance si elle est trouvée,
       sinon, d'inserer l'instance updaté dans table1_update.
 
 - En cas de delete sur Table1 :
     de faire un delete sur table1
     de faire un select sur Table1_insert et d’y détruire l’instance si elle est trouvée
       sinon de faire un select sur Table1_update et d’y détruire l’instance si elle est trouvée en l'inserant dans Table1_delete
       sinon de faire un insert de l’instance supprimée dans Table1_delete
 
A la fin on est donc en mesure de matérialiser :
les instances qui n'existaient pas et qui existent maintenant,
les instance qui existent maintenant et qui n'existaient pas,
les instances qui ont été modifiées.
 
Si c’est possible, si quelqu’un peut me faire un exemple de déclaration de ces trigger ce serait génial (j'y connais rien à ces trucs là).
 
Merci d’avance.

pourquoi ne pas rajouter des colonnes d'historisation de dates directement dans ta table plutot que d'utiliser des triggers ?
parce que ca va te manger des ressources de realiser une double mise a jour de tables

Effectivement les temps de traitement risquent d'être un peu alongés mais les traitements font globalement beaucoup plus d'acces aux données que de mise à jour et cet aspect est moins important sur une base dédié au tests par contre :
 
Car cela prendrait trop de temps de requêter toute les tables de la base pour obtenir les informations modifiées (certaines tables peuvent contenir des dizaines de millions d'instances).
 
Les traitements ne sont pas prévus pour alimenter cette nouvelle colonne et il serait trop coûteux de les adapter dans ce sens.
 
Enfin, cette méthode ne permet pas d'historiser les suppressions.

Personne ne peut me confirmer la faisabilité ?

en trigger tu peux tout faire, mais pourquoi avoir fais trois tables differentes et pas une seule avec une colonne te donnant le type de mise a jour ? ce sera plus simple a gerer.
sinon pour la syntaxe d'un trigger, une petite recherche sur google

la solution sera différente selon le SGBD

Merci pour vos réponses.
 
Trois tables ou une table avec une clef supplémentaire, effectivement je me suis posé la question mais le principe reste le même.
 
Ma question initiale portait sur la faisabilité. Si c'est faisable je verrais dans un second temps comment.
 
Le SGBD utilisé peut différer selon le client. Le produit utilise Sybase ou Oracle. Qu'entends tu par "solution" ? Syntaxe des trigger ?
 
Sinon, pour google, j'ai bien tenté, ca me donne un nombre considérable de page mais je n'arrive pas a trouver la syntaxe adéquate  
notament pour faire ce genre de chose : " de faire un select dans Table1_delete et d'y supprimer l'instance si elle est trouvée et de faire un insert dans table1_update , sinon de faire un insert dans Table1_insert"

sous Oracle tu peux lire les archives avec logminer par exemple

L'idéal est d'avoir une méthode d'identification des différences identique sur les deux SGBD (même si les paramétrages des base de données peuvent être différents : trigger etc...) de manière à ce que l'outils qui va scanner les différences n'ai pas a se poser la question du SGBD.
 
et j'ai cru comprendre que les journaling Oracle ou Sybase sont :
 - compliqués à analyser
 - tres différent entre Oracle et Sybase
 - trop riche car si une instance a été updater 3 fois pendant le process ils vont me dire que A est devenu A' puis A'' et enfin B
alors que moi la seule chose qui m'intéresse c'est de savoir que le contenu de B a été modifié pendant le traitement.
 

qui peut le plus peut le moins