Choisir le bon outil

code est lancé ou pour des applications
qui requièrent des paramètres de sortie multiples.

L’un des avantages des déclencheurs est d’être lancés dès
que l’événement base de données spécifié se produit, sans
que le développeur puisse s’y opposer. Revers de la médaille,
cette caractéristique des déclencheurs peut être gênante
parce que l’application appelante ignore parfois l’existence
du déclencheur. Pour cette raison, il vaut mieux réserver les
déclencheurs à  des processus autonomes
comme l’écriture d’un enregistrement
d’audit, plutôt que de les utiliser pour des activités,
comme la validation de données, qui
demandent la communication entre le
déclencheur et le programme qui l’a activé.
Il est une autre fonction des déclencheurs
qui est à  la fois un avantage et un inconvénient
: un déclencheur s’activera pour chaque
transaction du type désigné. Par exemple, si
l’on met à  jour chaque enregistrement d’un fichier dans le
cadre du traitement de nuit et un déclencheur update est assigné
pour activation, il s’activera pour chaque enregistrement
du fichier. Le seul moyen pour arrêter le traitement du
déclencheur consiste à  supprimer et à  recréer celui-ci.
Les déclencheurs étaient présents sur l’iSeries depuis la
V3R1. Mais l’ajout des déclencheurs SQL en V5R1 apporte
une excellente solution à  certains problèmes de programmation
pour lesquels ils étaient auparavant peu pratiques. A
titre d’exemple, considérons un déclencheur pour le fichier
maître Customer. Malgré l’importante activité de ce fichier,
nous ne nous intéressons qu’aux changements apportés au
code d’état client. Avec un déclencheur externe, nous
sommes limités à  attribuer un déclencheur update, qui s’activera
chaque fois que le fichier sera modifié de quelque façon.
Ensuite, dans notre programme déclencheur, nous pouvons
vérifier si le code d’état a changé et, dans la négative,
terminer le traitement. Cependant, ce modèle peut être inacceptable
parce que peu performant. Un déclencheur SQL
qui ne s’active que si le code d’état client est modifié, améliorera
nettement la performance.
Des trois fonctions base de données couvertes ici, les
procédures stockées sont les plus faciles à  comprendre. En
règle générale, on peut utiliser une procédure stockée
chaque fois que l’on songerait à  utiliser un programme de
service, une procédure ILE ou un appel de programme. Les
procédures stockées sont en principe utilisées pour un traitement
lourd spécifique aux bases de données, comme valider
des transactions, calculer des commissions ou déterminer
la présence d’articles en stock. Comme une procédure
stockée est appelée explicitement et peut accepter des paramètres
d’entrée et de sortie, elle donne plus de contrôle
qu’un déclencheur. Cependant, contrairement aux déclencheurs,
les procédures stockées peuvent être contournées
ou ignorées par les développeurs d’applications. On ne peut
donc pas utiliser des procédures stockées pour assurer l’intégrité
des données de la même manière qu’on utiliserait des
déclencheurs. Si l’on veut absolument que des enregistrements
d’audit soient écrits pour chaque transaction, par
exemple, on choisira plutôt un déclencheur qu’une procédure
stockée.
Les UDF sont particulièrement utiles quand on veut répéter
une petite quantité de traitement pour chaque ligne
qu’une instruction SQL affecte. En utilisant une UDF plutôt
que d’écrire manuellement le code chaque fois, on garantit
que le calcul se déroulera chaque fois de la même manière.
Par ailleurs, les UDF permettent de gommer les incompatibilités
existant entre des bases de données. Supposons que
votre application actuelle utilise une base de données Oracle
et une fonction SQL intégrée qui n’est pas disponible pour
UDB DB2 pour iSeries. En écrivant une UDF iSeries de même
nom que la fonction intégrée Oracle, on simplifiera la migration
de l’application sur l’iSeries.