Un trigger (ou trigger) c’est un peu comme un « callback » dans une base de données, qui réagit à certains événements. En gros, un trigger, c’est une réaction automatique à des opérations comme INSERT, UPDATE ou DELETE sur des tables.
Imagine que t’as un assistant intelligent qui fait des trucs à ta place. Par exemple, à chaque fois que tu ajoutes une nouvelle entrée pour un étudiant, l’assistant met à jour automatiquement la date de dernière modification. Un trigger dans une base de données fait exactement ça : il « écoute » les événements et lance une réaction programmée.
Un trigger combine deux choses :
- Événement : il se passe un truc dans la table (genre, une insertion de ligne).
- Fonction trigger : le code qui s’exécute quand l’événement se produit.
un trigger ne peut pas exister sans être lié à une fonction. C’est la fonction qui définit quoi faire quand le trigger se déclenche.
Exemples d’utilisation des triggers
Voyons quelques situations où les triggers peuvent vraiment servir.
- Mise à jour automatique des données
Tu veux que dans la table où tu stockes les infos sur les étudiants, il y ait un champ last_modified qui se met à jour tout seul à chaque modif. Plutôt que de le faire à la main à chaque fois, tu peux créer un trigger qui s’en charge pour toi.
- Logging des modifications
Tu veux savoir qui modifie quoi et quand dans une table. Un trigger peut ajouter automatiquement une entrée dans une table d’audit (logs) à chaque fois qu’une donnée change.
- Validation des données
Si tu ajoutes des données dans une table qui doivent respecter certaines règles (genre, l’âge d’un étudiant doit être supérieur à 18 ans), un trigger peut vérifier les données avant l’insertion.
- Calculs automatiques
Dans la table orders tu stockes les commandes, et à chaque nouvelle commande, il faut mettre à jour le total des achats du client. Au lieu de le faire à la main, un trigger peut s’en occuper automatiquement.
Quand utiliser les triggers
Maintenant qu’on voit ce qu’ils peuvent faire, parlons de quand il vaut vraiment le coup d’utiliser des triggers.
Logging et audit : les triggers sont parfaits pour créer des logs d’audit et suivre les changements dans les tables critiques.
Maintien de l’intégrité des données : par exemple, si tu supprimes un cours de la base, un trigger peut supprimer automatiquement tous les étudiants liés à ce cours, pour éviter les données « orphelines ».
Automatisation des tâches répétitives : ça peut être la mise à jour de valeurs calculées, de données agrégées, etc.
Implémentation de la logique métier dans la DB : au lieu de tout mettre dans le code de l’appli, tu peux déplacer une partie de la logique directement dans la base de données.
Avantages des triggers
Comme tu l’as sûrement compris, les triggers c’est un outil puissant. Voilà ce qu’ils apportent :
Automatisation : intervention humaine minimale. Par exemple, le tracking des utilisateurs qui modifient les données se fait tout seul.
Moins de code dupliqué : au lieu de forcer les devs à écrire la logique de mise à jour ou de validation dans chaque appli, on peut l’intégrer dans la DB.
Assurer l’intégrité des données : un trigger peut être une couche de protection en plus pour que les données restent toujours correctes.
Inconvénients des triggers
Évidemment, comme tout outil, les triggers ont aussi leurs défauts. Jetons un œil au côté obscur :
Débogage compliqué : les triggers bossent « en coulisses ». S’ils ne font pas ce qu’on attend, les déboguer peut être galère.
Risques de ralentissement : si un trigger est trop complexe ou appelé trop souvent, ça peut ralentir l’exécution des requêtes SQL.
Logique cachée : quand la logique métier est « enterrée » dans les triggers, c’est plus dur pour les devs de piger ce qui se passe vraiment dans la base.
Cas d’utilisation réels
Exemple 1 : Logging des modifications
Imaginons qu’on a une table students où on stocke les infos sur les étudiants. On veut suivre les changements sur les enregistrements. Pour ça, un trigger va ajouter une entrée dans la table audit_log à chaque fois qu’on modifie les données d’un étudiant.
Exemple 2 : Mise à jour automatique
Dans la table students il y a une colonne last_modified. On veut que sa valeur soit mise à jour à chaque modif des données d’un étudiant. On peut faire ça avec un trigger qui se lance après une mise à jour.
GO TO FULL VERSION