Les procédures stockées regroupent des instructions SQL enregistrées dans une base de données, puis exécutées sur demande. Elles peuvent centraliser des opérations récurrentes, comme inscrire un étudiant, attribuer un groupe ou traiter plusieurs notes.
Leur proximité avec les fonctions prête parfois à confusion : elles ne répondent pas aux mêmes besoins et leurs compromis pèsent sur la performance, la sécurité et la maintenabilité. Pour choisir avec discernement, il faut comparer leurs usages, leurs mécanismes d’erreur et leur rôle dans les transactions.
A retenir :
- Traitements métier centralisés et exécutables à la demande
- Paramètres IN, OUT et INOUT adaptés aux échanges nécessaires
- Gestionnaires d’erreurs et transactions pour protéger les données
- Compromis de portabilité, de sécurité et de maintenabilité
Procédures stockées SQL : usages et différences avec les fonctions
Le choix entre procédure et fonction dépend d’abord du résultat attendu et de la logique métier à exécuter. Une inscription à un cours, par exemple, peut vérifier les places disponibles, sélectionner un groupe et créer l’association correspondante.
Procédure ou fonction : choisir le bon outil
Dans cette distinction, la procédure orchestre généralement des opérations, tandis que la fonction sert davantage un calcul ou la production d’une valeur. Une procédure peut ne rien retourner, appeler une fonction et, selon le système, s’appeler elle-même.
À la différence d’une fonction, elle ne renvoie pas une valeur scalaire avec RETURN : des paramètres OUT servent notamment à transmettre un résultat. Selon la documentation MySQL, les paramètres peuvent être IN, OUT ou INOUT, suivant leur sens d’échange.
Comparaison des outils SQL :
Critère
Procédure stockée
Fonction
Usage habituel
Orchestration d’opérations
Calcul ou valeur auxiliaire
Résultat
Facultatif, notamment par OUT
Valeur renvoyée selon le système
Appel d’une fonction
Possible
Les procédures ne sont généralement pas appelées comme une fonction
Exemple métier
Inscrire un étudiant à un cours
Calculer une somme ou une donnée dérivée
Paramètres, appel et documentation d’une procédure
Une fois le besoin défini, les paramètres rendent explicites les informations entrantes et les résultats attendus. Dans MySQL, une procédure se crée avec CREATE PROCEDURE et s’exécute avec CALL.
Par exemple, une procédure de somme peut recevoir deux opérandes en IN et fournir le total en OUT. Selon la documentation MySQL, la variable passée en sortie permet ensuite de lire le résultat après l’appel.
Repères pour concevoir l’interface :
- IN pour les données fournies par l’appelant
- OUT pour transmettre une valeur calculée
- INOUT pour lire puis modifier un paramètre
- En-tête documenté pour décrire rôle, paramètres et résultats
Erreurs et sécurité : maîtriser les procédures stockées
Après avoir défini les échanges, il faut prévoir les situations où une instruction échoue. Une contrainte violée, une clé dupliquée ou une référence absente peut interrompre un traitement et laisser les données dans un état inattendu.
Gestion des erreurs SQL et des paramètres
Dans une procédure MySQL, un gestionnaire peut intercepter une classe d’erreurs ou une condition particulière. Un gestionnaire EXIT arrête le bloc concerné, tandis que CONTINUE reprend son exécution après le traitement de l’erreur.
Selon la documentation MySQL, les gestionnaires se déclarent dans les procédures et peuvent cibler notamment SQLEXCEPTION, SQLWARNING ou NOT FOUND. GET DIAGNOSTICS permet de récupérer des informations sur l’erreur pour produire un message exploitable.
Contrôles utiles avant l’exécution :
- Validation des données reçues et des références associées
- Gestion explicite des contraintes et erreurs prévisibles
- Message d’erreur utile sans divulgation d’informations sensibles
- Permissions limitées aux opérations réellement nécessaires
Transactions SQL : COMMIT et ROLLBACK
Lorsque plusieurs écritures forment une seule opération, une transaction permet de les valider ensemble ou de les annuler. Pour l’import de notes d’une classe, une note invalide peut justifier l’annulation de toutes les insertions du lot.
Le principe est simple : START TRANSACTION ouvre le travail, COMMIT confirme les changements et ROLLBACK les annule. Les effets exacts dépendent toutefois du moteur de stockage et des instructions exécutées.
Étapes d’un traitement atomique :
- Ouverture d’une transaction avant les écritures liées
- Exécution des requêtes SQL et vérification des résultats
- Validation par COMMIT si toutes les opérations réussissent
- Annulation par ROLLBACK dès qu’une erreur compromet le lot
Performance et maintenabilité : les débats autour des procédures stockées
Une transaction bien conçue protège la cohérence, mais ne suffit pas à garantir une architecture durable. Le lieu où réside le code influence aussi les déploiements, les tests, la portabilité et la dette technique.
Performance, sécurité et portabilité des bases de données
Centraliser un traitement près des données peut réduire certains échanges entre application et serveur. Cela ne garantit pas automatiquement une meilleure performance : les requêtes, les index, les volumes et les plans d’exécution restent déterminants.
Les droits d’exécution doivent également être limités, surtout lorsqu’une procédure accède à des données sensibles. La portabilité peut devenir plus difficile si le code dépend de la syntaxe, des types ou des gestionnaires propres à un moteur.
Compromis à évaluer :
- Exécution centralisée, mais dépendance accrue au serveur de données
- Moins d’allers-retours possibles, sans garantie de gain systématique
- Contrôle des droits, avec vérification du contexte d’exécution
- Code réutilisable, mais différences possibles entre moteurs SQL
Bonnes pratiques pour limiter la dette technique
Pour une équipe qui maintient plusieurs applications, une procédure longue et peu documentée peut devenir un point de blocage. Décrire les paramètres, les erreurs possibles et les effets transactionnels facilite les tests et les interventions ultérieures.
Il est utile de réserver ces objets aux traitements cohérents, de versionner leur définition et de tester les cas limites. Une règle métier complexe mérite aussi une décision explicite : la placer dans la base ou dans l’application, selon les compétences et les besoins de déploiement.
Source : MySQL, « Référence des erreurs serveur MySQL 8.0 ».
Un mot qui se comprend dossier après dossier
Qu'il s'agisse de philosophie bouddhiste, de méditation, de culture tibétaine, d'industrie durable, de linguistique ou de bien-être, chaque rubrique raconte une facette différente de la même question : comment un même mot peut porter, à la fois, une pensée millénaire et un usage bien actuel. Rien n'est figé : chaque contexte nouveau peut encore faire évoluer ce sens.
Pour aller plus loin
- Comparer plusieurs sources avant de juger la portée d'une traduction ou d'une définition
- Replacer chaque terme dans son contexte culturel réel, pas seulement sa traduction littérale
- S'intéresser aux usages vivants de la langue autant qu'aux définitions figées
- Observer comment un même mot évolue d'un domaine à l'autre au fil du temps
