Quelques détails sur ces trois grandes notions employées par le MySQL. On verra dans quels cas il est préférable de passer par des fonctions, des procédures, des triggers, ou bien s’il est préférable de laisser ces traitements sur le poste client.
Procédures stockées
Les deux grandes spécificités des procédures face aux fonctions :
- Une procédure ne renvoie pas forcément de valeur.
- Dans une procédure, on a accès aux tables de données (si les droits utilisateurs le permettent bien sûr).
Fonctions
A la différence des procédures stockées, les fonctions sont beaucoup plus spécifiques :
- Elle doivent impérativement retourner un résultat qui est préalablement déclaré.
- On ne peut pas, dans une fonction, avoir accès aux tables contenant les données.
- De nombreuses fonctions natives MySQL sont accessibles, permettant de traiter l’information de façon très optimisée.
Triggers
Les triggers, ou déclencheurs, sont des instructions qui sont programmées pour s’exécuter avant, ou après qu’une modification sur la table dénomée ne soit faite.
- Les transactions InnoDB ne sont pas gérées.
- Pas de possibilité d’invoquer des tables : on ne peut pas accéder aux autres tables (pas d’historisation dans une table de logs par exemple);
- Impossible de faire appel à des procédures stockées (notamment pour contourner la limitation précédente).
- Une utilisation abusive des triggers provoque une surcharge au niveau de la consommation CPU sur les requêtes initiales.
Quelle option choisir ?
L’écriture des procédures permet de simplifier grandement l’écriture de code d’une application lourde. Le temps de calcul est généralement beaucoup plus intéressant dans ce cas également. Cela est également conseillé si les postes clients doivent être ménagés. Enfin, en supposant que le traitement à faire doit l’être à partir de plusieurs applications, cela permet de centraliser, et rendre plus portable le traitement. Le code n’est à déboguer qu’à un endroit… Enfin, un tel traitement qui s’exécute sur le serveur permet également de réduire l’utilisation de la bande passante, en limitant le nombre de communications entre le client et le serveur pour chaque partie de ce traitement.
On évitera par contre d’utiliser l’option des procédures stockées quand son traitement n’est utilisé quand pour un seul cas d’utilisation, dans une seule application, à un seul endroit, etc. On n’aurait dans ce cas que les inconvénients de cette solution sans en avoir les avantages. L’utilisation abusive des traitements côté serveur peut impliquer une surcharge de ce dernier. On envisagera, si de tels traitements se révèlent nécessaires, à les passer sur des serveurs de réplication (lecture seule), ou via un système de clustering afin de répartir les charges.