Partie II
Programmation procédurale
262
© Éditions Eyrolles
Déclencheurs
Concernant MySQL, les déclencheurs n’existent que depuis la version 5. Comme nous le
verrons, ils sont limitatifs en termes de fonctionnalités et relativement instables (P. Gulutzan
citait, en parlant de la version bêta dans son livre blanc toujours présent (au moment de l’impression de ce livre) en page d’accueil du site de MySQL, MySQL 5.0 Triggers : « Triggers are very
new. There are bugs. … Do not try triggers with a database that has important data in it… »).
Bien que beaucoup d’améliorations aient été apportées, les déclencheurs qui modifient les
tables ne sont pas encore à mon sens tout à fait fiables. Prudence donc avec vos données.
Toutes les limitations que nous allons détailler seront sans doute résolues au fur et à mesure
des prochaines versions majeures du serveur. Songez qu’avant la version 5.0.10, les
déclencheurs ne pouvaient même pas accéder à la base !
Généralités
D’un point de vue général et sans parler de MySQL, la plupart des déclencheurs (triggers)
peuvent être vus comme des sous-programmes résidents associés à un événement particulier
(insertion, modification d’une ou de plusieurs colonnes, suppression) sur une table (ou une
vue). Une table (ou vue) peut « héberger » plusieurs déclencheurs ou aucun. Pour certains
SGBD, il existe d’autres types de déclencheurs que ceux associés à une table (ou vue) afin de
répondre à des événements qui ne concernent pas les données (exemple : connexion d’un
utilisateur particulier, suppression d’une table, démarrage ou arrêt du serveur, déconnexion
d’un utilisateur, etc.).
À la différence des sous-programmes, l’exécution d’un déclencheur n’est pas explicite (par
CALL par exemple), c’est l’événement de mise à jour de la table qui lance automatiquement le
code programmé dans le déclencheur. On dit que le déclencheur « se déclenche » (l’anglais le
traduit mieux : fired trigger).
À quoi sert un déclencheur ?
En théorie, un déclencheur permet de :
q
Programmer toutes les règles de gestion qui n’ont pas pu être mises en place par des
contraintes au niveau des tables. Par exemple, la condition : une compagnie ne fait voler
un pilote que s’il a totalisé plus de 60 heures de vol dans les 2 derniers mois, sur le type
d’appareil du vol en question, ne pourra pas être programmée par une contrainte et nécessitera l’utilisation d’un déclencheur.
q
Déporter des contraintes au niveau du serveur et alléger ainsi la programmation client.
q
Renforcer des aspects de sécurité et d’audit.
q
Programmer l’intégrité référentielle et la réplication dans des architectures distribuées,
avec l’utilisation de liens de bases de données.
Programmation procédurale
262
© Éditions Eyrolles
Déclencheurs
Concernant MySQL, les déclencheurs n’existent que depuis la version 5. Comme nous le
verrons, ils sont limitatifs en termes de fonctionnalités et relativement instables (P. Gulutzan
citait, en parlant de la version bêta dans son livre blanc toujours présent (au moment de l’impression de ce livre) en page d’accueil du site de MySQL, MySQL 5.0 Triggers : « Triggers are very
new. There are bugs. … Do not try triggers with a database that has important data in it… »).
Bien que beaucoup d’améliorations aient été apportées, les déclencheurs qui modifient les
tables ne sont pas encore à mon sens tout à fait fiables. Prudence donc avec vos données.
Toutes les limitations que nous allons détailler seront sans doute résolues au fur et à mesure
des prochaines versions majeures du serveur. Songez qu’avant la version 5.0.10, les
déclencheurs ne pouvaient même pas accéder à la base !
Généralités
D’un point de vue général et sans parler de MySQL, la plupart des déclencheurs (triggers)
peuvent être vus comme des sous-programmes résidents associés à un événement particulier
(insertion, modification d’une ou de plusieurs colonnes, suppression) sur une table (ou une
vue). Une table (ou vue) peut « héberger » plusieurs déclencheurs ou aucun. Pour certains
SGBD, il existe d’autres types de déclencheurs que ceux associés à une table (ou vue) afin de
répondre à des événements qui ne concernent pas les données (exemple : connexion d’un
utilisateur particulier, suppression d’une table, démarrage ou arrêt du serveur, déconnexion
d’un utilisateur, etc.).
À la différence des sous-programmes, l’exécution d’un déclencheur n’est pas explicite (par
CALL par exemple), c’est l’événement de mise à jour de la table qui lance automatiquement le
code programmé dans le déclencheur. On dit que le déclencheur « se déclenche » (l’anglais le
traduit mieux : fired trigger).
À quoi sert un déclencheur ?
En théorie, un déclencheur permet de :
q
Programmer toutes les règles de gestion qui n’ont pas pu être mises en place par des
contraintes au niveau des tables. Par exemple, la condition : une compagnie ne fait voler
un pilote que s’il a totalisé plus de 60 heures de vol dans les 2 derniers mois, sur le type
d’appareil du vol en question, ne pourra pas être programmée par une contrainte et nécessitera l’utilisation d’un déclencheur.
q
Déporter des contraintes au niveau du serveur et alléger ainsi la programmation client.
q
Renforcer des aspects de sécurité et d’audit.
q
Programmer l’intégrité référentielle et la réplication dans des architectures distribuées,
avec l’utilisation de liens de bases de données.