Salut et bienvenue dans ce nouvel épisode du podcast de Code Garage,
je m'appelle Nicolas Bandavernard et aujourd'hui,
on va parler des procédures stockées en base de données.
Donc dans le monde SQL, une procédure stockée, c'est tout simplement un script
prédéfinie, en tout cas que le développeur ou la développeuse va venir créer
et stocker directement dans le système de gestion de base de données
et qui sera exécuté à la demande, soit via simplement une commande SQL,
soit parfois qui pourrait être exécuté par une autre procédure stockée.
On va avoir une chaîne de procédures qui s'exécute les unes des autres.
A noter que parfois on parle simplement de sprox pour stored procédure.
Donc chaque procédure va ressembler à un peu une fonction en programmation classique
et donc chacune de ces fonctions va posséder un nom des paramètres du code SQL à exécuter
et éventuellement aussi des données à retourner.
Alors évidemment une procédure peut ne prendre aucun paramètre
et elle peut aussi ne rien retourner du tout comme une fonction classique en programmation.
Les procédures stockées, elles sont vraiment faites pour faciliter
l'exécution de tâches répétitives ou de tâches complexes en SQL.
Ça peut être des calculs, des mises à jour de la manipulation de données,
de la génération automatique de données, des choses comme ça.
Mais on peut évidemment se demander pourquoi est-ce qu'on va stocker du code
dans la base de données plutôt que dans le code logique, le code métier de notre application.
Et bien on va voir ça et en fait les procédures stockées,
elles ont quatre avantages clés qui fait que c'est très intéressant de les utiliser quand on peut.
Bon d'abord évidemment le premier point hyper logique c'est la réduction de la redondance.
Mais ça c'est comme n'importe quelle fonction en programmation,
ça vous évite d'écrire le même code SQL à plusieurs endroits,
simplement en l'encapsulant dans une procédure stockée que vous allez appeler
un nombre de fois que vous voudrez.
Mais en plus il y a quand même un cas particulier,
c'est que si jamais votre base de données elle est utilisée par plusieurs applications,
et bien vous n'avez pas besoin de partager ce code logique entre vos applications.
En tout cas vous allez le partager mais directement au travers d'une procédure stockée dans votre SGPD.
Ensuite le deuxième point c'est l'amélioration des performances.
Parce que comme elles sont directement stockées sur le serveur,
ces procédures stockées peuvent être précompilées,
qui va réduire le temps d'exécution par rapport à des requêtes classiques,
un ensemble de requêtes classiques.
Mais en plus si vous avez plusieurs requêtes qui s'enchaînent,
et que vous auriez dû faire des allers-retours entre votre serveur d'application
et votre serveur de base de données,
et bien en fait tous ces appels intermédiaires là, on va pouvoir les supprimer.
Donc on élimine le temps de ces requêtes,
et en plus on allège le trafic réseau.
Donc c'est vraiment un double bonus.
Ensuite on a la sécurité,
parce que en fait ça nous donne la possibilité,
par exemple quand on passe pour l'écriture ou la suppression ou la modification de données
dans une base de données,
et bien par exemple on peut passer par des règles de sécurité,
où on va dire,
et bien un utilisateur classique,
un utilisateur par exemple de notre application,
notre serveur d'application,
va pouvoir lire toutes les données,
mais pour modifier ou supprimer des données,
et bien il sera obligé de passer uniquement par les procédures stockées,
ce qui permet d'ajouter une couche de sécurité supplémentaire,
même si on met la main sur votre utilisateur de base de données,
et bien il y a quand même des choses qui seront pas accessibles.
Bon, qu'on ne pourra pas modifier quand on veut,
il y aura des garde-fous dans les procédures stockées.
Et enfin évidemment,
ça revient un petit peu à ce que je disais au début,
la réduction de la redondance,
et bien là c'est la maintenance qui est simplifiée,
parce que évidemment les modifications que vous allez faire
dans votre logique de données,
vous allez pouvoir les faire au niveau de la procédure stockée,
vous n'allez pas avoir besoin de mettre à jour le code des applications, etc.
Tout ça, ça se fait directement là-dessus,
donc c'est juste, c'est un peu une conséquence
de la réduction de la redondance,
comme n'importe quelle fonction en programmation.
Maintenant,
il faut savoir que la procédure stockée,
ce n'est pas non plus l'outil ultime,
ok, c'est un des outils en SQL
qui va nous permettre d'écrire de meilleures applications,
mais ce n'est pas 100% positif,
il y a quelques inconvénients à les utiliser.
Notamment, la première, c'est la dépendance vis-à-vis de votre système de gestion de base de données.
Évidemment, les procédures stockées
sont souvent spécifiques à un SGPD,
parce qu'on utilise un langage un petit peu spécifique,
on va en reparler un petit peu après,
ce qui peut limiter la portabilité du code
entre différents systèmes,
même différents systèmes SQL,
si jamais vous passez d'un système SQL à un autre,
mais encore plus si vous changez carrément
de système de base de données
pour certaines parties de votre application.
Il y a aussi une complexité qui est un peu accrue,
notamment sur le débeugage et la gestion des erreurs,
ça peut être beaucoup plus complexe
à faire qu'avec du code applicatif,
on va dire classique,
et ça peut rendre, en tout cas,
la mise à jour et le déploiement un peu plus complexe,
parce que la mise à jour,
quand on le fait en production,
ça peut être un petit peu compliqué,
il peut y avoir des délais
où il faut d'abord mettre à jour le schéma de données
qui est lié à la procédure,
et ensuite modifier cette procédure-là,
mais du coup, on peut avoir un petit laps de temps
où notre serveur n'est pas aussi disponible
qu'il devrait l'être, etc.
Donc ça, ce n'est pas toujours évident.
Sur une petite application qui n'a pas du trafic 24-24,
ce n'est pas du tout un problème,
mais sur d'autres systèmes,
il va falloir mettre en place des outils
justement pour faire les migrations de sa base de données,
où on peut émigrer à la fois ce schéma,
ces données et surtout ces procédures stockées.
Alors, est-ce que toutes les bases de données SQL
supportent les procédures ?
Alors, la majorité des SGB des modernes,
on va dire, prennent en charge des procédures stockées,
donc par exemple, MySQL,
la supportent depuis la version 5.0.
PostgreSQL les supporte avec un langage
qui s'appelle PL-PGSQL,
Microsoft SQL Server, évidemment, les supportent aussi.
MariaDB, évidemment, comme c'est compatible avec MySQL,
ça supporte les procédures stockées,
et Oracle, eh bien, supporte les procédures stockées
grâce à son langage qui s'appelle PL-SQL.
Alors, je vous en ai parlé très rapidement aussi avec PostgreSQL.
En fait, PL-SQL, qui veut dire
Procedural Language Structured Quail Language,
c'est pour SQL.
En fait, c'est un langage, justement,
comme dit, un procédural, qui a été développé par Oracle
et qui est, à l'origine, spécialement conçu,
justement pour étendre les fonctionnalités du SQL standard,
puisque le SQL standard, c'est de la modification de données,
de la récupération de données, etc.
Mais du coup, ce langage PL-SQL,
eh bien, ça incorpore des structures de programmation classiques.
C'est des boucles, des conditions,
des blocs de code, des choses comme ça,
dans à la fois soit les requêtes SQL,
mais surtout, dans les procédures stockées.
Et donc, c'est un petit peu de ce premier langage là
que se sont inspirés les autres SGBD
pour créer leur système de procédures
et leur langage.
Soit ils ont augmenté le SQL qu'ils gèrent,
soit ils ont créé un langage un peu différent,
un peu supplémentaire, comme la Fépos-Grèce.
J'espère que cet épisode vous aura plu
et que vous aurez appris ou aidé à comprendre
le concept de procédures stockées au SQL.
Moi, je vous donne rendez-vous la semaine prochaine
pour un prochain épisode,
mais juste avant de vous laisser,
je voulais vous dire que, évidemment,
je vous invite à aller faire un tour sur cotirigarage.fr,
mais là, en plus, vous allez pouvoir y retrouver
dans les derniers articles de blog,
eh bien, un article dédié justement au procédure stocké
avec un exemple de création de procédures stockées
pour SQL Server,
mais globalement, la syntaxe, on en a parlé,
elle est très commune aux autres SGBD.
Et donc, ça peut vous permettre de voir
un petit peu de visualiser encore,
un petit peu mieux, comment on s'en sert.
Et puis surtout, quelle utilité on a.
Voilà, on a pris le cas d'une génération automatique
de facture.
Donc voilà, c'est à la fois quelque chose de simplifié
et en même temps quelque chose qui serait vraiment utile
dans une application.
Donc voilà, n'hésitez pas à aller faire un tour sur cotirigarage.fr
pour retrouver tous nos articles de blog,
tous les épisodes de podcast,
et évidemment, tous nos cours complets
pour apprendre des langages, des frémoires,
que tout ce dont vous avez besoin pour continuer à progresser.
Je vous donne rendez-vous la semaine prochaine
pour un prochain épisode. Salut !