Que sont les procédures stockées? A quoi servent-elles?
Si je prends l’exemple de la programmation traditionnelle, une procédure stockée pourra être attribuée à une fonction. Plutôt que de réecrire sans arrêt la même chose, je crée une procédure stockée qui va me faire mon travail. Je peux lui passer des paramètres (ou non). Par contre, ma procédure ne me retournera rien. Elle se contente de faire ce que je lui demande (a contrario d’une function sous mysql qui elle pourra me retourner 1 ou plusieurs enregistrement)
Un exemple basic, tiré de la documentation MySQL:
delimiter //
CREATE PROCEDURE simpleproc (OUT param1 INT)
BEGIN
SELECT COUNT(*) INTO param1 FROM t;
END //
delimiter ;Il suffira de l’appeler (call simpleproc(@toto)) pour récupérer le retour du count. Notez les 2 commandes “delimiter” avant et après la création de la procédure stockée. C’est nécessaire afin de pouvoir disposer du ; de fin de requete dans la procédure, sinon mysql ne sait pas faire la différence entre le code dedans et dehors (il interpréterais le ; comme étant la fin du CREATE, et donc génère une erreur).
Et le trigger maintenant?
Pour ceux qui ont des notions d’éléctronique, le trigger est un élément qui réagit à un changement de statut (par exemple, on mets un trigger sur un état de sortie, et quand cet état change, on envois un signal. Il réagit donc non pas sur un état 0 ou 1, mais bien sur le changement d’état, de 0 VERS 1). Sous MySQL, c’est la même chose, ou presque. Le trigger va réagir à un update, insert ou delete d’une table bien précise, et va exécuter du code lorsque cela arrive.
L’utilité? par exemple mettre a jour par MySQL une table liée en MyISAM (cela évite que le développeur l’oublie dans son code PHP). Ou, et c’est à cela que je voulais en venir, mettre à jour une table intermédaire en MEMORY… Car c’est bien la que se trouve la puissance d’une optimisation de base de données… Réussir à mettre ensemble tout les outils mis à notre disposition…
Pour cela, et ce sera l’objet d’un autre billet, nous allons intégrer 3 outils de MySQL en une action:
– Une table MEMORY
– Un trigger
– Une procédure stockée
L’objectif? Disposer d’une table contenant de nombreuses données, ou des donnée provenant de multiples tables, disposant d’un temps d’accès très faible (je compte en 100 et 1000 fois plus rapide la récupération de donnée d’une table MEMORY a une table MyISAM…), mais en permanence à jour…
Mais, et ce sera la conclusion de ce billet, pourquoi ne pas utiliser une view, certains me diront? Effectivement, tant que les cas restent simples, avec peu de donnée, une view est efficace, mais quand on doit synthétiser des données venant de plusieurs tables, avec des if, des sous-requêtes, des jointures multiples, des opérations, on se retrouve rapidement à passer de tables a 10’000 données a plusieurs milliards dans la requête (table temporaire)!