Réponse

Les triggers sont des objets de base de données spéciaux qui lancent automatiquement l'exécution d'un certain code (généralement en SQL ou dans des langages d'extension procédurale, comme PL/pgSQL pour PostgreSQL) lorsqu'un événement se produit : INSERT, UPDATE ou DELETE sur une table.

Avantages :

• Application centralisée de la logique métier et validation des données.
• Automatisation de l'audit (par exemple, l'historique des modifications).

Inconvénients :

• Exécution cachée — il n'est pas toujours évident qu'un trigger s'est exécuté.
• Diminution des performances lors de fréquents changements de tables.
• Difficultés de débogage et risques de récursion (triggers récursifs).
• Les migrations de données deviennent plus compliquées.

Quand appliquer :

• Audit des données.
• Création automatique d'enregistrements liés.
• Mise en œuvre de contrôles de contraintes impossibles par des moyens standards.

Exemple de trigger (PostgreSQL) :

CREATE TABLE employee_audit (
  id SERIAL PRIMARY KEY,
  employee_id INT,
  old_salary NUMERIC,
  new_salary NUMERIC,
  changed_at TIMESTAMP
);

CREATE OR REPLACE FUNCTION audit_salary()
RETURNS TRIGGER AS $$
BEGIN
  IF NEW.salary <> OLD.salary THEN
    INSERT INTO employee_audit(employee_id, old_salary, new_salary, changed_at)
    VALUES (OLD.id, OLD.salary, NEW.salary, NOW());
  END IF;
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_salary_update
AFTER UPDATE ON employees
FOR EACH ROW
EXECUTE FUNCTION audit_salary();

Question piège

Peut-on à l'intérieur d'un trigger mettre à jour la même table sur laquelle il est configuré ? Que se passera-t-il ?

Réponse :
Si le trigger est configuré sur un événement, disons, UPDATE d'une table et exécute à l'intérieur un autre UPDATE de cette même table, cela entraînera une récursion infinie (boucle) et un échec de la commande ou une erreur de dépassement de profondeur des triggers. Par conséquent, surveillez toujours pour éviter la récursion, ou utilisez des options qui autorisent/interdisent les appels récursifs.

Exemple :

-- Cette construction peut boucler le trigger :
CREATE OR REPLACE FUNCTION recursive_update()
RETURNS TRIGGER AS $$
BEGIN
  UPDATE employees SET salary = salary * 1.01 WHERE id = NEW.id; -- sera déclenché à nouveau
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

---

Histoire

Dans un CRM de comptabilité, un trigger a été mis en place pour enregistrer automatiquement les opérations dans un journal lors de la modification de la table des transactions. Sous une charge élevée, le service est devenu plus lent, et l'analyse a montré : le trigger prend beaucoup de temps pour l'insertion dans le journal et n'a pas été optimisé (par exemple, ne journalisait que les événements significatifs).

---

Histoire

Dans un projet de gestion des inventaires, un trigger BEFORE INSERT a été utilisé pour calculer l'ID de la position. Une logique incorrecte de l'ID a provoqué la duplication des données, et l'erreur est restée non remarquée pendant longtemps, car elle fonctionnait "en arrière-plan".

---

Histoire

Dans une plateforme RH, un trigger effectuait une mise à jour massive d'enregistrements dans les tables parent et enfant à chaque INSERT. En raison d'erreurs dans la logique du trigger, une récursion s'est produite, bloquant complètement toutes les opérations sur les tables. Il a fallu désactiver le trigger et effectuer une complexité de rollback pour débloquer les tables.