trigger ou pas trigger ?

Cet article a été repris sur le blog de Clever Age.

Suite à une discussion intéressante avec des collègues, nous nous sommes posés la question suivante : « nos données, pour les applications que nous réalisons doivent être maintenues en cohérence suivant les règles métiers de l’application ; faut-il coder ces mécanismes dans la partie modèle du logiciel ou directement dans la base de données ? ».

Par exemple, lors d’un enregistrement d’une donnée sur la table A, il faut mettre à jour la table B. On peut envisager deux manières :

1/ fabriquer un trigger (ou gachette en french) dans notre base de données qui va automatiquement se charger de cela

Par exemple sous Oracle :

 CREATE TRIGGER trigger_insertion AFTER INSERT ON table_A  FOR EACH ROW  WHEN (NEW.col_a <= 10)  BEGIN      INSERT INTO table_B VALUES(:NEW.col_b, :NEW.col_a);  END;

2/ surcharger la classe gérant l’enregistrement de la table A avec un code particulier s’occupant de notre table B

Par exemple avec PHP et propel :

<?php // on surcharge la fonction save de la classe métier gérant la table A public function save() {   if ($this->getColA() <= 10) {     $tableB = new TableB();     $tableB->setColA = $this->getColB();     $tableB->setColB = $this->getColA();     $tableB->save();   }   return parent::save } ?>

Le trigger est beaucoup plus performant en terme de ressources hardware, il permet aux développeurs du code PHP (dans notre exemple) de faire complètement abstraction de cette problématique de mise à jour. D’un point de vue purement technique c’est une option assez tentante.

Un autre argument pour le trigger est que deux applications différentes (un batch et un client lourd par exemple) peuvent profiter de l’intelligence du trigger.

Toutefois, il est nécessaire de prendre en compte quelques autres paramètres :

La portabilité

En intégrant un trigger dans votre application, celle ci devient dépendante du type de base de données. En pratique cela pose généralement peu de problèmes :

  • les changements de bases de données au sein d’un SI sont peu fréquents et souvent faits à un rythme inférieur à la production des applications
  • le coût de réécriture des triggers sera vraisemblablement marginal par rapport à l’ensemble du coût d’une éventuelle migration

La dispersion de l’intelligence métier

En écrivant votre logique métier dans le code l’application et des triggers, on décrit à deux endroit différents notre logique métier. De plus, les traitements inclus dans les triggers ne sont pas forcément accessibles lors de l’édition du code applicatif, et vice versa. On augmente finalement les possibilités de ne plus s’y retrouver. Il faudra produire et maintenir une documentation de qualité pour faire diminuer ce risque.

La dispersion des compétences

C’est à mes yeux le problème le plus important. En plus de produire un système documentaire complet, il faudra maintenir des compétences sur votre application en elle même et votre base de données « intelligente ». Il faudra donc être sûr de disposer de la compétence d’un dba capable de dialoguer avec vos équipes.

L’argument du gain de performance est peu valable au vu des coûts actuels du hardware par rapport à la prestation intellectuelle. Reste à voir si vous avez vraiment besoin d’un système de gestion de données autonomes. Si oui, il faudra vraisemblablement en faire plus et exposer vos données via des web services. Je vous conseille donc de ne pas installer de triggers pour vos applications ; ou au moins pas avant d’avoir bien évalué les risques liés à leurs utilisations.

Publicités

2 réflexions au sujet de « trigger ou pas trigger ? »

  1. Nicolas Hoizey

    Il y a une petite erreur ici à priori:
    pages.citebite.com/y1r7y3…

    Sinon, j’ajouterais que les triggers peuvent être intéressants pour limiter le nombre de requêtes à la base de données quand il y a des mises à jour multiples en cascade. La latence réseau des requêtes entre le serveur d’application et le SGBD peut vite devenir importante.

    Sinon, je trouve que ce post aurait tout à fait sa place sur un autre blog… 😉

Les commentaires sont fermés.