Bonjour,
 
Dans le cadre d'un projet dans ma boite on va mettre en place des tables de journaling pour pouvoir monitorer les mises à jour effectuées sur une BD pendant l'exectution d'un ou plusieurs traitements.
 
En ayant un modèle de donnée de la forme :  
 
   Table1  
   Clef  Champ11  
   Data  Champ12  
 
Apres déclaration de la table suivante :  
 
   Journal_Table1  
   Clef  Type_maj
 Champ11  
   Data  Champ12  
 
Avec Type_maj qui serait un champ alimenté avec 'D' pour delete, 'U' pour update et 'I' pour Insert.
 
A l'aide de trigger on va faire les opérations suivantes :  
 
 - En cas d'insert dans Table1 :  
     de faire un select dans Journal_Table1 avec Type_maj = 'D' et d'y supprimer l'instance si elle est trouvée et de faire un insert des même données dans Journal_table1 avec Type_maj = 'U'  
       sinon de faire un insert dans Journal_Table1 avec Type_maj = 'I'  
 
 - En cas d'update sur une instance de Table1 :  
     de faire un select dans Journal_Table1 avec Type_maj = 'I' et d'y updater l'instance si elle est trouvée,  
       sinon, de faire un select dans Journal_table1 avec Type_maj = 'U' d'y updater l'instance si elle est trouvée,  
       sinon, d'inserer l'instance updaté dans Journal_table1 avec Type_maj = 'U'.  
 
 - En cas de delete sur Table1 :  
     de faire un select sur Journal_Table1 avec Type_maj = 'I' et d’y détruire l’instance si elle est trouvée  
       sinon de faire un select sur Journal_Table1 avec Type_maj = 'U' et d’y détruire l’instance si elle est trouvée en l'inserant dans Journal_Table1 avec Type_maj = 'D'  
       sinon de faire un insert de l’instance supprimée dans Journal_Table1 avec Type_maj = 'D'  
 
A la fin on devrait donc être 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.  
 
Par contre, on va devoir faire aussi des tests de performance et ces tables de journaling risquent de fausser les résultats.
 
J'ai donc besoin de pouvoir désactiver ces trigger de manière assez souple.
 
ex : si je fait un test fonctionnel je lance mes traitement après avoir activé les triggers sinon, si je suis sur un test de perf, je lance mes traitements après les avoir désactivés.
 
Je pourrais conditionner l'exectution des trigger par la présence d'une instance dans  une table spécifique du SGBD mais je crains que cela ne soit pas neutre sur la rapidité du traitement.
 
Est-ce que vous voyez une autre solution qui serait totalement neutre (ou vraiment non-significative) ?
 
Merci d'avance.
 
A+

pourquoi ne pas plutôt travailler sur les logs de la base ? a mon avis ce sera bcp plus simple

Pour 10000 raisons mais c'est pas la question =)

si tu veux qu'on t'aide, il faut aussi qu'on comprenne ton besoin réel.
 
moi ya un truc que je comprends pas : si tu veux absolument utiliser des triggers c'est que tu veux l'histo complète des màj de tes tables.
et dans ce cas là les triggers font partie entière de ton appli et doivent donc rentrer dans tes tests de perf.
 
si tu veux juste des stats de màj de table alors là je vois pas d'utilité aux triggers

Oui et non car les trigger serait activés uniquement en interne dans le cadre de tests fonctionnel et ne seraient jamais déployés sur des base de prod client donc c'est exclus de mes tests de perf.
 

1/ c'est quoi ton SGBD ?
2/ SQL Server 2005 :

3/ Ca doit être vaguement la même syntaxe sur tous les autres SGBD (peut-être avec un ALTER)

Merci de ton conseil.
 
Il y a un point que je n'avais pas précisé c'est qu'il y a 350 tables dans le MdD et donc je me vois mal lancer 350 requetes sql avant chacun de mes tests (en plus ça me ferais perdre quelques dixaines de seconde ce qui à l'échelle de milliers de tests n'est pas souhaitable).
 
Ce que je cherche à faire c'est juste ajouter une condition d'éxécution dans le trigger lui-meme dans une forme qui n'aurait pas ou tres peu d'impact sur la rapidité du traitement.
 
Mais à défaut d'une meilleure solution je me conterais de ça même si ça me pose d'autres contraintes.

tu sais pas lire ?
 
DISABLE TRIGGER ALL ON DATABASE
 

à partir du moment où le trigger démarre, même s'il ne fait rien, il a consommé 99% du temps qu'il consommera dans tous les cas : il a créé une transaction, et chargé tout un environnement d'automation... à côté des traîtements que tu fais derrière, c'est énorme.

Si mais j'ai jamais dit que je voulais désactiver tous les trigger de la base =)
il y en a d'autres auxquels je ne veux surtout pas toucher ...
 
Ceci dit si effectivement le fait de l'executer même s'il ne fait rien est déja consommateur l'idée tombe à l'eau et ta première solution devient la seule possible.
 
Merci pour les infos.
 
PS : le SGBD peut être Oracle ou Sybase dans toute une serie de versions