La majorité des triggers SQL procurent des fonctionnalités équivalentes aux triggers externes actuels, et aussi une poignée de fonctions dont ne disposent pas les triggers externes.
Comme une table, un trigger a un nom en deux parties qui inclut un nom de schéma (bibliothèque). Le nom du trigger doit
être unique dans un schéma. Comme dit précédemment, la commande CL ADDPFTRG est améliorée pour permettre d’attribuer des noms aux triggers externes également.
Les triggers SQL supportent les mêmes événements déclenchants que les triggers externes : mise à jour, suppression, ou insertion d’une ligne dans une table. En outre, un trigger SQL permet de n’appliquer un événement déclenchant de mise à jour qu’à une certaine colonne plutôt qu’à chaque colonne de la ligne. Seuls les triggers SQL donnent la possibilité d’étendre un événement déclenchant à une colonne ou à un groupe de colonnes. Cette délimitation (scoping) est obtenue en ajoutant une clause OF à la spécification d’événement UPDATE – par exemple, » …UPDATE OF adresse, ville, pays, code postal . » Cette option exclusive à SQL peut améliorer grandement les performances en permettant de n’exécuter un trigger que quand une (ou plusieurs) colonne est modifiée, plutôt que chaque fois qu’une colonne quelconque dans une ligne est modifiée.
Les triggers SQL et externes utilisent les mêmes temps d’activation (déclenchement). Le temps d’activation est toujours avant ou après que son événement déclencheur survienne dans la base de données. On fait souvent référence aux triggers en combinant les propriétés d’événement et de temps, comme dans un trigger » avant insertion » ou un trigger » après mise à jour « .
Nous avons vu que de multiples triggers peuvent avoir le même événement et temps de déclenchement. En raison des standards, un trigger avant (before) ne permet pas à la logique du trigger d’effectuer des modifications. Le standard SQL empêche à jamais un trigger » avant » d’activer un autre trigger avant ; cette activation est empêchée par la clause NO CASCADE. Par conséquent, les instructions de modification de données (INSERT, UPDATE, DELETE, et CREATE) ne sont pas autorisées dans un trigger avant.
Les triggers SQL offrent un contrôle supplémentaire dont les triggers externes sont dépourvus. L’instruction SQL qui cause le déclenchement d’un trigger peut affecter une ou plusieurs lignes dans la base de données. Ainsi, une instruction SQL Delete permet de supprimer une ou plusieurs lignes d’une table.
Quand on définit un trigger SQL, on peut préciser si le trigger doit être appelé une seule fois pour une telle instruction SQL (FOR EACH STATEMENT) ou une fois pour chaque ligne modifiée (FOR EACH ROW). On appelle cela la granularité ou l’orientation du trigger, et les deux types de triggers sont dits triggers statement-level (au niveau instruction) ou triggers row-level (au niveau ligne). (Les triggers externes sont toujours définis comme des triggers au niveau ligne .)
Si une ligne est supprimée par l’instruction Delete, un trigger au niveau instruction se déclenche une fois et un trigger au niveau ligne se déclenche une fois. Quand 10 lignes sont supprimées, le trigger au niveau instruction se déclenche une fois, mais un trigger au niveau ligne se déclenche 10 fois. Si zéro ligne est supprimée, un trigger au niveau instruction se déclenche encore une fois, mais un trigger au niveau ligne ne se déclenche pas du tout. L’option au niveau instruction ne peut concerner que des triggers après. S’il existe plus d’un trigger par événement, l’exécution des triggers au niveau instruction et au niveau ligne est entremêlée, d’après l’ordre dans lequel les triggers sont créés.
Il existe une autre option propre à SQL pour les triggers : le mode trigger. Il y a deux modes trigger pour les triggers SQL : DB2SQL et DB2ROW. DB2SQL est le mode supporté par les autres produits DB2 UDB. DB2ROW est le mode qui a toujours été utilisé par les triggers externes. Le mode trigger entraîne une subtile différence dans l’exécution du trigger. Le mode DB2ROW déclenche le trigger après chaque changement de ligne. Comme on s’en doute, ce mode ne peut être spécifié que sur des triggers au niveau ligne. A l’inverse, le mode DB2SQL attend que tous les changements de ligne aient eu lieu, puis appelle le trigger.
Cette différence n’est pas la même que la granularité au niveau ligne versus instruction. Voyons un exemple de trigger au niveau ligne, de type suppression (delete), en utilisant les deux modes pour mieux comprendre les différences. Si l’instruction delete déclenchante supprime 10 lignes, la version DB2ROW du trigger déclenche après suppression de chaque ligne – 10 fois au total. La version DB2SQL de ce trigger de suppression déclenche aussi 10 fois. Cependant, avec le mode DB2SQL, le trigger ne se déclenche qu’une fois que les 10 lignes sont supprimées. Les données trigger pour chaque suppression de ligne sont sauvegardées. Ensuite, une fois toutes les lignes supprimées, ces données sauvegardées sont utilisées pour déclencher le trigger pour chaque ligne supprimée. On voit donc que le mode DB2SQL est moins efficace que DB2ROW parce que chaque ligne est en fait traitée deux fois. Le mode DB2SQL n’est supporté que sur les triggers » après « . Si DB2SQL est spécifié sur un trigger » avant « , il est automatiquement converti au mode DB2ROW.
Malgré les différences de comportement des modes, le résultat final d’un trigger est généralement le même, quel que soit le mode utilisé : DB2SQL ou DB2ROW. La seule exception à cette règle est un trigger autoréférençant. Si un trigger DB2ROW effectue une opération agrégée (comme un comptage sur la table sous-jacente du trigger), il peut renvoyer une valeur différente de celle d’un trigger DB2SQL. L’opération agrégée DB2SQL n’est effectuée qu’une fois que toutes les opérations sur les lignes ont eu lieu. La fonction agrégée DB2ROW est exécutée sur la table après chaque opération sur les lignes.
Pour comprendre cette différence, réexaminons l’exemple précédent d’un trigger d’annulation (delete) où instruction déclenchante a supprimé 10 lignes. Si la logique du trigger faisait un comptage des lignes dans la table sous-jacente, le trigger DB2SQL renverrait la même valeur de comptage (nombre total de lignes = 10) pendant chaque exécution. Le comptage des lignes en mode DB2ROW serait différent à chaque activation du trigger : nombre total de lignes = 1 à la première exécution, nombre total de lignes = 2 à la seconde exécution, et ainsi de suite.
Découvrez toutes nos actualités à travers des interviews, avis, conseils d'experts, témoignages clients, ainsi que les dernières tendances et solutions IT autour de nos 4 univers produits : Poste de travail, Affichage et Collaboration, Impression et Infrastructure.
