une vraie suppression pure et dure, avec effacement des données, donc une requête DELETE ;
un archivage, qui masquera les données dans l'application mais les conservera dans la base de données.
Dans ce cas, une solution possible est d'ajouter aux tables contenant des données archivables une colonne archive, pouvant
contenir 0 (la ligne n'est pas archivée) ou 1 (la ligne est archivée). Pour une vraie suppression, on peut utiliser simplement un ON
DELETE RESTRICT|CASCADE|SET NULL, qui se répercutera sur les tables référençant les données supprimées. Par
contre, dans le cas d'un archivage, on utilisera plutôt un trigger pour traiter les lignes qui référencent les données archivées, par
exemple en les archivant également.
Historisation des actions
On veut parfois garder une trace des actions effectuées sur la base de données, c'est-à-dire par exemple, savoir qui a modifié telle
ligne, et quand. Avec les triggers, rien de plus simple, il suffit de mettre à jour des données d'historisation à chaque insertion,
modification ou suppression. Soit directement dans la table concernée, soit dans une table utilisée spécialement et exclusivement
pour garder un historique des actions.
Mise à jour d'informations qui dépendent d'autres données
Comme pour les procédures stockées, une partie de la logique "business" de l'application peut être codée directement dans la
base de données, grâce aux triggers, plutôt que du côté applicatif (en PHP, Java ou quel que soit le langage de programmation
utilisé).
À nouveau, cela peut permettre d'harmoniser un traitement à travers plusieurs applications utilisant la même base de données.
Par ailleurs, lorsque certaines informations dépendent de la valeur de certaines données, on peut en général les retrouver en
faisant une requête SELECT. Dans ce cas, il n'est pas indispensable de stocker ces informations.
Cependant, utiliser les triggers pour stocker ces informations peut faciliter la vie de l'utilisateur, et peut aussi faire gagner en
performance. Par exemple, si l'on a très souvent besoin de cette information, ou si la requête à faire pour trouver cette information
est longue à exécuter.
C'est typiquement cet usage qui est fait des triggers dans ce qu'on appelle les "vues matérialisées", auxquelles un chapitre est
consacré dans la partie 6.
Création des triggers
Syntaxe
Pour créer un trigger, on utilise la commande suivante :
Code : SQL
CREATE TRIGGER nom_trigger moment_trigger evenement_trigger
ON nom_table FOR EACH ROW
corps_trigger
CREATE TRIGGER nom_trigger : les triggers ont donc un nom.
moment_trigger evenement_trigger : servent à définir quand et comment le trigger est déclenché.
ON nom_table : c'est là qu'on définit à quelle table le trigger est attaché.
FOR EACH ROW : signifie littéralement "pour chaque ligne", sous-entendu "pour chaque ligne
insérée/supprimée/modifiée" selon ce qui a déclenché le trigger.
corps_trigger : c'est le contenu du trigger. Comme pour les procédures stockées, il peut s'agir soit d'une seule
instruction, soit d'un bloc d'instructions.
Événement déclencheur
Trois événements différents peuvent déclencher l'exécution des instructions d'un trigger.
L'insertion de lignes (INSERT) dans la table attachée au trigger.
La modification de lignes (UPDATE) de cette table.
La suppression de lignes (DELETE) de la table.
Un trigger est soit déclenché par INSERT, soit par UPDATE, soit par DELETE. Il ne peut pas être déclenché par deux
événements différents. On peut par contre créer plusieurs triggers par table pour couvrir chaque événement.
Partie 5 : Sécuriser et automatiser ses actions
311/414
www.openclassrooms.com
un archivage, qui masquera les données dans l'application mais les conservera dans la base de données.
Dans ce cas, une solution possible est d'ajouter aux tables contenant des données archivables une colonne archive, pouvant
contenir 0 (la ligne n'est pas archivée) ou 1 (la ligne est archivée). Pour une vraie suppression, on peut utiliser simplement un ON
DELETE RESTRICT|CASCADE|SET NULL, qui se répercutera sur les tables référençant les données supprimées. Par
contre, dans le cas d'un archivage, on utilisera plutôt un trigger pour traiter les lignes qui référencent les données archivées, par
exemple en les archivant également.
Historisation des actions
On veut parfois garder une trace des actions effectuées sur la base de données, c'est-à-dire par exemple, savoir qui a modifié telle
ligne, et quand. Avec les triggers, rien de plus simple, il suffit de mettre à jour des données d'historisation à chaque insertion,
modification ou suppression. Soit directement dans la table concernée, soit dans une table utilisée spécialement et exclusivement
pour garder un historique des actions.
Mise à jour d'informations qui dépendent d'autres données
Comme pour les procédures stockées, une partie de la logique "business" de l'application peut être codée directement dans la
base de données, grâce aux triggers, plutôt que du côté applicatif (en PHP, Java ou quel que soit le langage de programmation
utilisé).
À nouveau, cela peut permettre d'harmoniser un traitement à travers plusieurs applications utilisant la même base de données.
Par ailleurs, lorsque certaines informations dépendent de la valeur de certaines données, on peut en général les retrouver en
faisant une requête SELECT. Dans ce cas, il n'est pas indispensable de stocker ces informations.
Cependant, utiliser les triggers pour stocker ces informations peut faciliter la vie de l'utilisateur, et peut aussi faire gagner en
performance. Par exemple, si l'on a très souvent besoin de cette information, ou si la requête à faire pour trouver cette information
est longue à exécuter.
C'est typiquement cet usage qui est fait des triggers dans ce qu'on appelle les "vues matérialisées", auxquelles un chapitre est
consacré dans la partie 6.
Création des triggers
Syntaxe
Pour créer un trigger, on utilise la commande suivante :
Code : SQL
CREATE TRIGGER nom_trigger moment_trigger evenement_trigger
ON nom_table FOR EACH ROW
corps_trigger
CREATE TRIGGER nom_trigger : les triggers ont donc un nom.
moment_trigger evenement_trigger : servent à définir quand et comment le trigger est déclenché.
ON nom_table : c'est là qu'on définit à quelle table le trigger est attaché.
FOR EACH ROW : signifie littéralement "pour chaque ligne", sous-entendu "pour chaque ligne
insérée/supprimée/modifiée" selon ce qui a déclenché le trigger.
corps_trigger : c'est le contenu du trigger. Comme pour les procédures stockées, il peut s'agir soit d'une seule
instruction, soit d'un bloc d'instructions.
Événement déclencheur
Trois événements différents peuvent déclencher l'exécution des instructions d'un trigger.
L'insertion de lignes (INSERT) dans la table attachée au trigger.
La modification de lignes (UPDATE) de cette table.
La suppression de lignes (DELETE) de la table.
Un trigger est soit déclenché par INSERT, soit par UPDATE, soit par DELETE. Il ne peut pas être déclenché par deux
événements différents. On peut par contre créer plusieurs triggers par table pour couvrir chaque événement.
Partie 5 : Sécuriser et automatiser ses actions
311/414
www.openclassrooms.com