Archives mensuelles : mai 2007

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.

Mozy : j’ai testé pour vous

J’ai souscrit à l’offre proposé par mozy qui propose, pour un peu plus de 4,95 $ US par mois un service de backups et restaurations illimités via internet.

Sauvegardes

Pour faire une première sauvegarde il faut tout d’abord s’inscrire sur le site de mozy. Vous pouvez commencer en choisissant l’offre limitée à 2Go de stockage en ligne. Il faut ensuite télécharger une application cliente (mozy fonctionne sous windows XP et MacOs X – le client MacOs est en béta mais, selon mes tests, me semble tout à fait utilisable).

A l’ouverture de l’application, on vous propose simplement de choisir parmi quelques sets de données (comme iTunes, iPhoto …) et/ou des dossiers ou fichiers sur votre disque dur.

Le backup démarre ensuite.

Vous pouvez constater que quand on veut sauver 40Go de données, il vaut mieux être patient. 😉

J’ai naturellement fait un test avec un jeux de données plus restreint. Ce qui est intéressant, c’est que par la suite, mozy va rester actif et profiter des moments de veille de votre ordinateur pour mettre à jour vos données. Clairement, vous pouvez oublier le système un fois celui ci mis en place ; et c’est vraiment appréciable. On a toutefois accès à tout moment au statut de l’application :

Restaurations

Une demande de restauration commence également par une visite sur le site de mozy. Une page permet de préparer vos données à restaurer.

Un point important est que l’on peut choisir de télécharger ces données ou se les faire envoyer via Fedex sous la forme de DVD. Cela peut être utile si on désire récupérer rapidement les fameux 40 Go !

Une fois la demande faite, vous recevez quelques minutes plus tard un sympathique email vous invitant à télécharger le tout.

Les données se présentent sous forme d’une image disque. Le chemin complet des données est reproduit dans l’image, il n’y a aucune ambigüités possible sur la provenance de ces dernières.

En conclusion

Pour moi mozy est ce que .Mac aurait dû être. C’est certainement un service très intéressant pour les particuliers consommateurs de numérique.

Google – le portail personnalisable !

Google propose maintenant un portail personnalisé – avec l’intégration de tous les outils google, ça va faire très très mal. (dommage pour netvibes ?)

Comme quoi, faire bouger des fenêtres en Ajax ça casse pas des briques, mais sortir un portail intégrant des killer apps comme celles de Google et c’est le pompon.