| Bien comprendre les Triggers |
|
La base de données générée par SQL remplace tranquillement les dds traditionnelles. A cette occasion, on se pose beaucoup de questions
sur la mise en oeuvre de triggers !
Voici quelques précisions qui vont vous aider à y voir un peu plus clair.
Tout d'abord une petite définition celle de Wikipedia par exemple :
Il est important de différencier les triggers en 2 grandes catégories de triggers : ceux qui doivent
s'exécuter avant et ceux qui doivent s'exécuter après.
1 Les triggers avant :
On peut également les classifier encore en 2 sous catégories
La première, les triggers de complémentation qui donnent des informations supplémentaires pour la mise à jour à effectuer
Exemple :
Vous avez dans votre fichier des informations de suivi datemodif, heure modif, user votre trigger les renseignera automatiquement
La deuxième, Les triggers de contrôle qui donnent l'autorisation pour faire quelque chose et fera planter le cas échéant l'application qui le lance.
Exemple :
qte en stock > qte demandé
Ce contrôle doit être rapide pour des questions de performance !
Le gros problème à ce jour c'est qu'on ne sait pas identifier facilement le trigger qui refuse les mises à jour
2 Les triggers après :
On peut également les classifier encore en 2 sous catégories
La première, les triggers d'historisation ou de log qui sont utilisés pour historiser des informations
Exemple :
Tracer toutes les manipulations de matières dangereuses
Log d'un traitement dans un fichier historique distinct du fichier sur lequel il est apposé, ou traçabilité pour audit ultérieur
La deuxième, les triggers de traitement après mise à jour
Exemple :
si qte en stock < qte mini lancer un réapprovisionnement
Il ne faut pas hésiter à soumettre ce traitement qui souvent ne nécessite pas une synchronisation
Une des grandes questions également à se poser est Trigger RPG ou SQL ?
Une des différences importantes est qu'en SQL on peut
Réduire le nombre d'exécution en choisissant les colonnes mise à jour
les enregistrements
on peut constater des ratios de 300 pour 1 dans certains cas
En clair, si vous pouvez le faire en SQL , n'hésitez pas !
De plus sur un pgm rpg lancez souvent ne pas hésiter à le monter en mémoire
setobjacc ....
En résumé
Les trigers sont trés interessants pour de nombreuses actions mais
attention à leurs manipulations (par exemple duplication de fichier ...)
Quelques conseils
Quand vous mettez en place des triggers de contrôle historiser les refus dans un fichier
ce qui vous permettra de suivre facilement vos erreurs !
Quand vous avez un trigger avant et après prévoyer un seul programme en RPG avec test du code mise à jour et
passer par une procédure pour un trigger sql, si vous devez changer vous n'aurez qu'une modif à faire
Ne jamais faire de mise à jour sur le fichier dans un trigger vous partirez en boucle !
Pensez à la sécurité qui peut gérer les triggers de ma base
|