philosophie de base des triggers, qui
part du principe qu’un trigger peut être
lancé à  partir de toute application dont
l’auteur ignore peut-être qu’un trigger est
associé à  un événement de base de données
particulier. Si vous décidez d’utiliser
des triggers pour valider des données, essayez
d’isoler le code de traitement d’erreurs.
Songez à  utiliser une file d’attente
de données, un fichier base de données
ou une file d’attente de messages distincte
(pas la file d’attente de messages
du programme) pour signaler les erreurs
à  l’application appelante. Vous pourriez
même utiliser un document XML pour
signaler des erreurs à  partir d’un programme
trigger (nous y reviendrons).

Le reporting d’erreurs est au coeur du
travail de conception d’applications utilisant
des triggers. Si le programme trigger
signale les erreurs directement à  l’application
appelante, on perd la séparation
de la fonction, qui est le principal avantage
des triggers. Par conséquent, dans
l’idéal, les triggers devraient être limités
aux fonctions dont on n’attend pas couramment
qu’elles signalent des conditions
d’erreur. Cela ne signifie pas qu’il
n’est pas nécessaire de prévoir le traitement
des erreurs dans les programmes
trigger, mais l’objectif d’un programme
trigger ne devrait pas être de communiquer
des erreurs à  l’application qui a provoqué
le déclenchement du trigger. Il devrait
être de traiter une tâche qui doit se
produire, sans défaillance, à  chaque modification
de la base de données, indépendamment
de l’origine de l’événement.
Ainsi utilisés, les triggers
améliorent considérablement votre kit
de développement d’applications.