Triggers
Les triggers (ou déclencheurs) sont des objets de la base de données. Attachés à une table, ils vont déclencher l'exécution
d'une instruction, ou d'un bloc d'instructions, lorsqu'une, ou plusieurs lignes sont insérées, supprimées ou modifiées dans la
table à laquelle ils sont attachés.
Dans ce chapitre, nous allons voir comment ils fonctionnent exactement, comment on peut les créer et les supprimer, et surtout,
comment on peut s'en servir et quelles sont leurs restrictions.
Principe et usage
Qu'est-ce qu'un trigger ?
Tout comme les procédures stockées, les triggers servent à exécuter une ou plusieurs instructions. Mais à la différence des
procédures, il n'est pas possible d'appeler un trigger : un trigger doit être déclenché par un événement.
Un trigger est attaché à une table, et peut être déclenché par :
une insertion dans la table (requête INSERT) ;
la suppression d'une partie des données de la table (requête DELETE) ;
la modification d'une partie des données de la table (requête UPDATE).
Par ailleurs, une fois le trigger déclenché, ses instructions peuvent être exécutées soit juste avant l'exécution de l'événement
déclencheur, soit juste après.
Que fait un trigger ?
Un trigger exécute un traitement pour chaque ligne insérée, modifiée ou supprimée par l'événement déclencheur. Donc si l'on
insère cinq lignes, les instructions du trigger seront exécutées cinq fois, chaque itération permettant de traiter les données d'une
des lignes insérées.
Les instructions d'un trigger suivent les mêmes principes que les instructions d'une procédure stockée. S'il y a plus d'une
instruction, il faut les mettre à l'intérieur d'un bloc d'instructions. Les structures que nous avons vues dans les deux chapitres
précédents sont bien sûr utilisables (structures conditionnelles, boucles, gestionnaires d'erreur, etc.), avec toutefois quelques
restrictions que nous verrons en fin de chapitre.
Un trigger peut modifier et/ou insérer des données dans n'importe quelle table sauf les tables utilisées dans la requête qui l'a
déclenché. En ce qui concerne la table à laquelle le trigger est attaché (qui est forcément utilisée par l'événement déclencheur), le
trigger peut lire et modifier uniquement la ligne insérée, modifiée ou supprimée qu'il est en train de traiter.
À quoi sert un trigger ?
On peut faire de nombreuses choses avec un trigger. Voici quelques exemples d'usage fréquent de ces objets. Nous verrons plus
loin certains de ces exemples appliqués à notre élevage d'animaux.
Contraintes et vérifications de données
Comme cela a déjà été mentionné dans le chapitre sur les types de données, MySQL n'implémente pas de contraintes d'assertion,
qui sont des contraintes permettant de limiter les valeurs acceptées par une colonne (limiter une colonne TINYINT à TRUE (1)
ou FALSE (0) par exemple).
Avec des triggers se déclenchant avant l'INSERT et avant l'UPDATE, on peut vérifier les valeurs d'une colonne lors de
l'insertion ou de la modification, et les corriger si elles ne font pas partie des valeurs acceptables, ou bien faire échouer la
requête. On peut ainsi pallier l'absence de contraintes d'assertion.
Intégrité des données
Les triggers sont parfois utilisés pour remplacer les options des clés étrangères ON UPDATE RESTRICT|CASCADE|SET
NULL et ON DELETE RESTRICT|CASCADE|SET NULL. Notamment pour des tables MyISAM, qui sont nontransactionnelles et ne supportent pas les clés étrangères.
Cela peut aussi être utilisé avec des tables transactionnelles, dans les cas où le traitement à appliquer pour garder des données
cohérentes est plus complexe que ce qui est permis par les options de clés étrangères.
Par exemple, dans certains systèmes, on veut pouvoir appliquer deux systèmes de suppression :
Partie 5 : Sécuriser et automatiser ses actions
310/414
www.openclassrooms.com
Les triggers (ou déclencheurs) sont des objets de la base de données. Attachés à une table, ils vont déclencher l'exécution
d'une instruction, ou d'un bloc d'instructions, lorsqu'une, ou plusieurs lignes sont insérées, supprimées ou modifiées dans la
table à laquelle ils sont attachés.
Dans ce chapitre, nous allons voir comment ils fonctionnent exactement, comment on peut les créer et les supprimer, et surtout,
comment on peut s'en servir et quelles sont leurs restrictions.
Principe et usage
Qu'est-ce qu'un trigger ?
Tout comme les procédures stockées, les triggers servent à exécuter une ou plusieurs instructions. Mais à la différence des
procédures, il n'est pas possible d'appeler un trigger : un trigger doit être déclenché par un événement.
Un trigger est attaché à une table, et peut être déclenché par :
une insertion dans la table (requête INSERT) ;
la suppression d'une partie des données de la table (requête DELETE) ;
la modification d'une partie des données de la table (requête UPDATE).
Par ailleurs, une fois le trigger déclenché, ses instructions peuvent être exécutées soit juste avant l'exécution de l'événement
déclencheur, soit juste après.
Que fait un trigger ?
Un trigger exécute un traitement pour chaque ligne insérée, modifiée ou supprimée par l'événement déclencheur. Donc si l'on
insère cinq lignes, les instructions du trigger seront exécutées cinq fois, chaque itération permettant de traiter les données d'une
des lignes insérées.
Les instructions d'un trigger suivent les mêmes principes que les instructions d'une procédure stockée. S'il y a plus d'une
instruction, il faut les mettre à l'intérieur d'un bloc d'instructions. Les structures que nous avons vues dans les deux chapitres
précédents sont bien sûr utilisables (structures conditionnelles, boucles, gestionnaires d'erreur, etc.), avec toutefois quelques
restrictions que nous verrons en fin de chapitre.
Un trigger peut modifier et/ou insérer des données dans n'importe quelle table sauf les tables utilisées dans la requête qui l'a
déclenché. En ce qui concerne la table à laquelle le trigger est attaché (qui est forcément utilisée par l'événement déclencheur), le
trigger peut lire et modifier uniquement la ligne insérée, modifiée ou supprimée qu'il est en train de traiter.
À quoi sert un trigger ?
On peut faire de nombreuses choses avec un trigger. Voici quelques exemples d'usage fréquent de ces objets. Nous verrons plus
loin certains de ces exemples appliqués à notre élevage d'animaux.
Contraintes et vérifications de données
Comme cela a déjà été mentionné dans le chapitre sur les types de données, MySQL n'implémente pas de contraintes d'assertion,
qui sont des contraintes permettant de limiter les valeurs acceptées par une colonne (limiter une colonne TINYINT à TRUE (1)
ou FALSE (0) par exemple).
Avec des triggers se déclenchant avant l'INSERT et avant l'UPDATE, on peut vérifier les valeurs d'une colonne lors de
l'insertion ou de la modification, et les corriger si elles ne font pas partie des valeurs acceptables, ou bien faire échouer la
requête. On peut ainsi pallier l'absence de contraintes d'assertion.
Intégrité des données
Les triggers sont parfois utilisés pour remplacer les options des clés étrangères ON UPDATE RESTRICT|CASCADE|SET
NULL et ON DELETE RESTRICT|CASCADE|SET NULL. Notamment pour des tables MyISAM, qui sont nontransactionnelles et ne supportent pas les clés étrangères.
Cela peut aussi être utilisé avec des tables transactionnelles, dans les cas où le traitement à appliquer pour garder des données
cohérentes est plus complexe que ce qui est permis par les options de clés étrangères.
Par exemple, dans certains systèmes, on veut pouvoir appliquer deux systèmes de suppression :
Partie 5 : Sécuriser et automatiser ses actions
310/414
www.openclassrooms.com