Bienvenue chez les artisans développeurs !

MariaDB / MySQL - Pourquoi utiliser des procédures stockées ?

Posté par Alexis
Dernière révision :

Il y a beaucoup de tutoriels vous expliquant comment créer vos procédures stockées, quelles instructions y sont disponibles, comment faire une boucle, comment ceci, comment cela...
Mais très peu vous expliquent pourquoi vous pourriez avoir besoin d'utiliser des procédures stockées dans vos bases MariaDB / MySQL. Je vais tenter, à travers mes expériences passées, de vous éclairer sur l'intérêt de ces dernières.

Depuis quelques années je n'utilisent plus que des procédure stockées. Pourquoi ?
Je trouve qu'elles ont pleins d'avantage :

1. Les procédures stockées minimisent la surface d'attaque

En effet, inutile d'autoriser l'utilisateur connecté pour SELECT, UPDATE, DELETE, ... Le seul droit EXECUTE suffit. L'avantage c'est que même en découvrant la structure de l'analyse, rien n'est possible sans connaître également le nom ET la syntaxe de la procédure stockée.
Avec le seul droit EXECUTE, votre utilisateur ne pourra pas réaliser de DELETE/UPDATE sur la base si aucune procédure stockée ne le prévoit.
Évidemment, tout ceci à un (léger) coût CPU et RAM. Mais la sécurité ne justifie-t-elle pas un léger overhead ?

2. Les procédures stockées pour exécuter des enchaînements d'ordre SQL

Quand je créé un client, je dois toujours créer également la liste d'applications qu'il a le droit d'installer, les licences, ...
Je pourrais faire cela du côté applicatif mais - 1 - cela exigerait plusieurs A/R avec la base de données et au niveau performance c'est pas terrible et - 2 - Je devrais créer des codes similaires sur 2 langages à savoir PHP et Windev.
Je pourrais également traiter ça par trigger mais je ne les aime guère car - 1 - je trouve qu'ils brouillent le déroulement logique du process en introduisant une espèce de hook assez compliqué à debugger et - 2 - Je pourrais exceptionnellement vouloir créer un client sans pour autant lui appliquer le même traitement.
Je préfère tout regrouper dans une procédure stockée. Ainsi, je maîtrise toutes les étapes nécessaires à la création d'un client et l'appel, qu'il soit effectué depuis PHP ou Windev, est identique. De plus, je ne fais qu'un seul A/R avec la BdD et ça c'est bon pour la vitesse d'exécution 😉.

3. Les procédures stockées permettent de faire des UPSERT

Comme vous le savez, les UPSERT ne sont pas gérés dans MySQL. Il y a bien quelques combines (REPLACE, ON DUPLICATE KEY UPDATE) pour simuler cet ordre SQL mais rien de très "propre".
Avec les procédures stockées non seulement c'est possible mais de manière propre et avec un retour d'information efficace. Je détaille tout ça dans ce billet.

4. Les procédures stockées amènent de la souplesse

Si vous devez légèrement (ou plus significativement) modifier votre modèle de données, elles vous seront d'une grande utilité. Sans procédure stockée c'est impossible de modifier les bases, mettre à jour les applications et les portails sans au minimum un downtime qui n'est pas toujours possible.
Avec les procédures stockées, c'est réalisable 8-) et je vous invite à découvrir comment sur ce billet.

5. Les procédures stockées afin d'améliorer les suppressions

Je n'aime guère utiliser CASCADE pour supprimer les enregistrement des tables externes. Je pense que le processus de suppression est trop critique pour ne pas lui consacrer un peu de temps et bien analyser les effets de bord qu'il pourrait engendré. De plus, ne pas utiliser CASCADE permet de limiter le coup du "big finger" qui risque de tout flinguer au moindre appui malencontreux sur la touche SUPPR à 3h du mat quand vous avez vos petits noeils qui commencent à être collés par la fatigue ! De plus, CASCADE ne fonctionne pas en dessous de n-1.
Dans ce cas (encore) les procédures stockées peuvent être d'une efficacité redoutable. Elles permettent d'encadrer le process de suppression, de gérer le cascading et même d'apporter son lot d'avantages lors des changements de schéma. Je vous invite à découvrir le découplage des entités lors de la suppression avec les procédures stockées dans ce billet.

6. Les procédures stockées pour appliquer le concept DRY au code SQL

Eh oui, souvenez-vous : On ne doit pas dupliquer son code (Don't Repeat Yourself - DRY). Or en saisissant plusieurs fois le même code SQL dans du PHP par exemple, eh bien on n'applique pas ce (très bon) précept ! Dommage non ?

Conclusion

Vous avez découvert les procédures stockées dans MariaDB / MySQL et vous trouvez ça génial / daubé ?
Vous êtes d'accord / pas d'accord avec les points évoqués ?
Tous vos commentaires sont les bienvenus !

Commentaires

Date Auteur Commentaire
2018-07-31 21:58:34azerdanke schön


Je ne suis pas un robot et je sais que