Blog

Blog

Les triggers : c'est le mal!

Un ami qui est prof à la fac me demandait un cas concret d'utilisation légitime de trigger... Et j'ai été bien embêtée.
Voici la réponse que je lui ai faite :
D'après mon expérience, les triggers sont rarement une bonne idée. Il faut vraiment se poser la question de l'intérêt du trigger. Par exemple, s'il sert à mettre à jour des enregistrements (techniques ou pas), pourquoi le programme ne le ferait-il pas dans la même transaction ? S'il sert à implémenter une règle métier pourquoi les contraintes d'intégrité ne suffisent-elles pas ?
Les triggers sont souvent utilisés à tord et à travers par les éditeurs de progiciels (et plus à tord qu'à travers), ce qui pose des problèmes de réplication (avec golden gate par exemple), des problèmes de performance, des problèmes de maintenance et des vérolage (attention néologisme) de système quand les rollbacks n'ont pas été pensés. (Il faut savoir que les triggers sont rarement développés par des gens qui connaissent les bases de données.) Je ne parle même des casse-têtes que ça génère pour migrer sur un autre SGBD!

C'était mon idée, mais j'aurai aimé avoir une validation d'un expert reconnu dans le monde... et j'ai trouvé (très facilement) !
Voici pourquoi Tom Kyte n'aime pas les triggers : http://www.oracle.com/technetwork/issue-archive/2008/08-sep/o58asktom-101055.html et là pourquoi Vikas Munjal, invité de Paul Randal sur son blog SQL Authority n'aime pas non plus : http://blog.sqlauthority.com/2013/01/24/sql-server-how-to-use-instead-of-trigger-guest-post-by-vikas-munjal-koenig-solutions/

Bref, j'ai répondu à côté de la question...

Pour répondre à la question, à savoir trouver un cas d'utilisation réelle (à défaut de légitime) de triggers, voici ce que je propose. Il est de coutume de toujours ajouter 4 colonnes systématiquement dans les tables d'une modèle de données : creation_user, creation_date, updating_user, updating_date. Cela permet d'assurer la traçabilité des données de la table.
On pourrait envisager de créer un trigger remplissant automatiquement ces données. Dans la pratique, on ne le fera pas car, en plus des raisons indiquées plus haut, les logiciels utilisent un login non lié à l'utilisateur pour se connecter à la base et du coup "select user from dual;" renverrait toujours le user utilisé par le logiciel, et non le user de la personne ayant fait la modification...

Dans le même genre, il y a ici un exemple d'audit des mouvements de données sur une certaine table http://stackoverflow.com/questions/11261929/auditing-50-columns-using-oracle-trigger.

Enfin, les triggers peuvent être utilisés pour faire de la réplication, même si c'est extrêmement lourd à mettre en place, à maintenir et à utiliser, tout en étant extrêmement poussif en exécution.

Bref, je pense toujours que c'est une mauvaise idée et qu'il serait plus intéressant d'apprendre aux étudiants à écrire leurs requêtes avec la norme SQL d'après 1992 (c'est-à-dire avec le mot-clé JOIN) pour qu'on ne perde pas du temps à expliquer aux jeunes comment écrire une requête maintenable.