3.

Requêtes préparées et
procédures stockées

 3.1 Requêtes préparées

 3.2 Procédures stockées
3.1 Requêtes préparées : variable
utilisateur
 Une requête préparée, c'est une requête stockée en mémoire (pour
la session courante), et que l'on peut exécuter à loisir
 Une variable utilisateur est une variable définie par l'utilisateur. Les
variables utilisateur MySQL sont toujours précédées du signe @.
 Une variable utilisateur peut contenir quatre types de valeur : entier
(6), réel (2,3), chaine de caractères (‘Bonjour’), ou chaine binaire
 Il existe également des variables système, qui sont des variables
prédéfinies par MySQL, et des variables locales, que nous verrons
avec les procédures stockées.
 La manière la plus classique de créer ou de modifier une variable
utilisateur est d'utiliser la commande SET
 SET @age = 24;
 SET @salut = 'Hello World !', @poids = 7.8; -- On peut créer plusieurs variables en
même temps
 SELECT @age, @poids, @salut; - - taper cette commande pour observer le
résultat

Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 66

3.1 Requêtes préparées : variable
utilisateur
 Affectation : Il est également possible d'assigner (affecter) une valeur
à une variable utilisateur directement dans une requête ou dans une
commande SET, en utilisant l'opérateur d'assignation :=
 SELECT @age := 32, @poids := 48.15, @perroquet := 4;
 SET @chat := 2;
 On peut aussi utiliser les variables utilisateur dans des requêtes ou
pour faire des calculs.
 SELECT id, sexe, nom, commentaires, espece_id
 FROM Animal
 WHERE espece_id = @perroquet; -- On sélectionne les perroquets

 SET @conversionDollar = 1.31564;

 -- On crée une variable contenant le taux de conversion des euros en dollars
 -- On sélectionne le prix des races, en euros et en dollars.
 SELECT prix AS prix_en_euros, ROUND(prix * @conversionDollar, 2) AS
prix_en_dollars, nom
 FROM Race;
 Une variable utilisateur non définie a pour valeur NULL

Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 67

3.1 Requêtes préparées : variable
utilisateur
 NB : Les variables utilisateur stockent des données.
 Elles permettent donc dynamiser un peu nos requêtes.
 Cependant, il n'est pas possible de les utiliser pour stocker un nom de
table ou de colonne que l'on introduirait ensuite directement dans la
requête. Ni pour stocker une partie de commande SQL.
 SET @table_clients = 'Client';
 SELECT * FROM @table_clients; --- génère une erreur
 Portée des variables utilisateur :
 Une variable utilisateur n'existe que pour la session dans laquelle elle
a été définie.
 Lorsque vous vous déconnectez, toutes vos variables utilisateur sont
automatiquement réinitialisées (à NULL).
 De plus, deux sessions différentes ne partagent pas leurs variables
utilisateur.
 Exercice : Faire des tests pour mesurer la portée des variables
utilisateur

Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 68

3.1 Requêtes préparées : principe,
syntaxe et exécution
 Principe
 Une requête préparée, c'est en fait un modèle de requête que l'on
enregistre et auquel on donne un nom.
 On va ensuite pouvoir l'exécuter en l'appelant grâce à son nom, et en
lui passant éventuellement un ou plusieurs paramètres.
 Par exemple, si vous avez régulièrement besoin d'aller chercher des
informations sur vos clients à partir de leur adresse e-mail dans une
session, plutôt que de faire :
 SELECT * FROM Client WHERE email = 'truc@email.com';
 SELECT * FROM Client WHERE email = 'machin@email.com';
 SELECT * FROM Client WHERE email = 'bazar@email.com';
 SELECT * FROM Client WHERE email = 'brol@email.com';
 Vous pouvez préparer une requête modèle :
 SELECT * FROM Client WHERE email = ?
 Où le ? représente un paramètre. Ensuite, il suffit de l'appeler par son
nom en lui passant 'truc@email.com‘ , ou 'machin@email.com‘
 Une requête préparée n'existe que pour la session qui la crée.
Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 69
3.1 Requêtes préparées : principe,
syntaxe et exécution
 Syntaxe : Pour préparer une requête, il faut renseigner 2 éléments :
 le nom que l'on donne à la requête préparée ;
 la requête elle-même, avec un ou plusieurs paramètres (représentés par un ?)
 La syntaxe est :
 PREPARE nom_requete
 FROM 'requete_preparable';
 Exemples
 -- Sans paramètre
 PREPARE select_race
 FROM 'SELECT * FROM Race';

 -- Avec un paramètre
 PREPARE select_client
 FROM 'SELECT * FROM Client WHERE email = ?';

Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 70

3.1 Requêtes préparées : principe,
syntaxe et exécution
 -- Avec deux paramètres
 PREPARE select_adoption
 FROM 'SELECT * FROM Adoption WHERE client_id = ? AND animal_id = ?';
 La requête à préparer doit être passée comme une chaîne de
caractères.
 Que le paramètre soit un nombre (client_id = ?) ou une chaîne de
caractères (email = ?), cela ne change rien. On ne met pas de
guillemets autour du ? dans la requête à préparer
 La chaîne de caractères contenant la requête à préparer ne peut
contenir qu'une seule requête (et non plusieurs séparées par un ;)
 Les paramètres ne peuvent représenter que des données, des
valeurs, pas des noms de tables ou de colonnes ni des morceaux de
commandes SQL.

Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 71

3.1 Requêtes préparées : principe,
syntaxe et exécution
 Comme la requête à préparer est donnée sous forme de chaine de
caractères, il est également possible d'utiliser une variable utilisateur
dans laquelle on enregistre tout ou partie de la requête à préparer.
 SET @req = 'SELECT * FROM Race';

 PREPARE select_race

 FROM @req;

 SET @colonne = 'nom';

 SET @req_animal = CONCAT('SELECT ', @colonne, ' FROM
Animal WHERE id = ?');
 PREPARE select_col_animal
 FROM @req_animal; -- Attention : on ne peut pas mettre la function
CONCAT () directement dans la clause FROM

Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 72

3.1 Requêtes préparées : principe,
syntaxe et exécution
 Exécution :
 Pour exécuter une requête préparée, on utilise la commande suivante
 EXECUTE nom_requete [USING @parametre1, @parametre2, ...];
 On utilise uniquement les variables utilisateur pour donner des valeurs
aux paramètres de la requête avec la clause USING
 Exemples
 EXECUTE select_race;

 SET @id = 3;
 EXECUTE select_col_animal USING @id;

 SET @client = 2;
 EXECUTE select_adoption USING @client, @id;

 SET @email = 'jean.fotso@email.com';

 EXECUTE select_client USING @email;

 SET @email = 'marie.achu@email.com';

 EXECUTE select_client USING @email;
Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 73
3.1 Requêtes préparées : principe,
syntaxe et exécution
 SET @email = 'fleurtrachon@email.com';
 EXECUTE select_client USING @email;

 SET @email = 'jeanvp@email.com';

 EXECUTE select_client USING @email;

 SET @email = 'johanetpirlouit@email.com';

 EXECUTE select_client USING @email;

 Pour supprimer une requête préparée, on utilise DEALLOCATE

PREPARE suivi du nom de la requête préparée
 DEALLOCATE PREPARE select_race;
 DEALLOCATE PREPARE select_client;
 DEALLOCATE PREPARE select_adoption ;
 DEALLOCATE PREPARE select_col_animal ;

 Les commandes PREPARE, EXECUTE et DEALLOCATE sont

rarement utilisés dans des situations réelles de développement
d’applications.
Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 74
3.1 Requêtes préparées : usage et utilité

 Usage
 MySQL est rarement utilisé seul. La plupart du temps, il est utilisé en
conjonction avec un langage de programmation, comme Java, PHP,
Python, etc.
 Un langage de programmation permet de gérer un programme, un site
web… et crée des requêtes SQL permettant de gérer la base de
données de l'application.
 Or, il existe des API (interfaces de programmation) pour plusieurs
langages, qui permettent de faire des requêtes préparées sans
exécuter vous-mêmes les commandes PREPARE, EXECUTE et
DEALLOCATE
 Exemples : l'API C MySQL pour le langage C, MySQL Connector/J
pour le Java, ou MySQL Connector/Net pour le .Net.
 Pour d'autres langages, des extensions ont été créées, en général
elles-mêmes basées sur l'API C MySQL, comme PDO pour le PHP
 Illustration : voir fichiers dans TP4 pour le C et PHP
 code C utilisant l'API MySQL pour préparer et exécuter une requête d'insertion
 code PHP utilisant l'extension PDO pour préparer et exécuter requête de sélection
Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 75
3.1 Requêtes préparées : usage et utilité

 Pourquoi apprendre la syntaxe SQL de PREPARE, EXECUTE et

DEALLOCATE si l'on ne s'en sert jamais ?
 D'abord, parce qu'il est toujours intéressant de savoir comment
fonctionnent les requêtes préparées.
 Ensuite, parce qu'il pourrait arriver qu'il n'existe aucune API ni
extension permettant de faire des requêtes préparées pour le langage
dans lequel vous programmez, auquel cas, il faudrait construire vos
requêtes préparées vous-mêmes.
 Ou vous pourriez tomber sur l'un des rares cas où il vous serait
nécessaire de préparer une requête directement en SQL.
 Enfin, vous aurez peut-être besoin de faire quelques tests impliquant
des requêtes préparées directement dans MySQL.
 Cependant, si une API ou une extension existe et répond à vos
besoins, utilisez-la !
 Elle sera généralement plus performante et plus sécurisée que ce que
vous pourriez faire vous-même.

Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 76

3.1 Requêtes préparées : usage et utilité

 Utilité : les requêtes préparées permettent de :

 protéger une application des injections SQL
 gagner en performance dans le cas d'une requête exécutée plusieurs fois par la
même session
 Dans une application Web, par exemple, un utilisateur interagit celle-
ci en lui envoyant des informations qui peuvent être sous forme de
requêtes SQL
 En programmation on dit qu’il ne faut « jamais faire confiance aux
données fournies par l’utilisateur » ("Never trust user input").
 Car l'utilisateur peut, volontairement ou non, faire ce que l'on appelle
une injection SQL et provoquer un comportement inattendu et très
souvent indésirable, voire dangereux, pour les données.
 Les injections SQL sont un type de failles exploitables par l'utilisateur
 Une injection SQL consiste pour un utilisateur à fournir des données
contenant des mots-clés SQL ou des caractères particuliers qui
vont détourner ou modifier le comportement des requêtes
construites sur la base de ces données

Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 77

3.1 Requêtes préparées : usage et utilité

 Par exemple, supposons que dans un site Web vous avez un bouton
qui permet de supprimer un membre à partir de son id envoyé au clic
sur le bouton "Supprimer Compte"
 On a donc une requête incomplète DELETE FROM Membre WHERE id = et
de l’autre côté l’id du membre e.g. 4 (obtenu d’une zone de saisie)
 Le langage de programmation utilisé va mettre les deux ensemble
pour créer la requête DELETE FROM Membre WHERE id = 4;
 Et maintenant, un pirate s'amuse à modifier la donnée envoyée par le
bouton "Supprimer compte" (eh oui, c'est faisable, et même plutôt
facile). À la suite du numéro d'id, il ajoute OR 1 = 1
 On obtient au final la requête DELETE FROM Membre WHERE id = 4 OR 1 = 1;
 Comme la seconde condition sera toujours remplie, c'est l'horreur :
toute votre table Membre est effacée !
 Et voilà ! Vous avez été victime d'une injection SQL.

 Solution : requête préparée. Comment ?

Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 78

3.1 Requêtes préparées : usage et utilité

 Solution : requête préparée. Comment ?

 Quand on utilise les requêtes préparées, on lie une valeur à un

paramètre de la requête préparée grâce à la fonction
correspondante dans le langage de programmation utilisé
 Ainsi le type du paramètre attendu est également donné,
explicitement ou implicitement.
 La plupart du temps :
 soit une erreur sera générée si la donnée de l'utilisateur ne correspond pas au type
attendu,
 soit la donnée de l'utilisateur sera rendue inoffensive (par l'ajout de guillemets qui
en feront une simple chaîne de caractères, par exemple).
 Par ailleurs, lorsque MySQL injecte les valeurs dans la requête, les
mots-clés SQL qui s'y trouvent pour une raison ou une autre ne sont
pas interprétés (puisque les paramètres n'acceptent que des valeurs,
et pas des morceaux de requêtes).

Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 79

3.1 Requêtes préparées : usage et utilité

 Gagner en performance : dans quelle situation ?

 Lorsque l'on exécute une simple requête (sans la préparer), voici les 5
étapes qui sont effectuées :
1. La requête est envoyée vers le serveur.
2. La requête est compilée par le serveur (traduite du langage SQL
compréhensible pour nous, vers un "langage machine" dont se sert le
serveur).
3. Le serveur crée un plan d'exécution de la requête (quelles tables utiliser ?
quels index ? dans quel ordre ?…).
4. Le serveur exécute la requête.
5. Le résultat de la requête est renvoyé au client.
 Lorsqu’il s’agit d'une requête préparée, on a 8 étapes réparties en
deux phases
 Préparation de la requête (5 étapes)
 Exécution de la requête (3 étapes)

Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 80

3.1 Requêtes préparées : usage et utilité

 Préparation de la requête (5 étapes)

1. La requête est envoyée vers le serveur, avec un identifiant.
2. La requête est compilée par le serveur.
3. Le serveur crée un plan d'exécution de la requête.
4. La requête compilée et son plan d'exécution sont stockés en mémoire par le
serveur.
5. Le serveur envoie vers le client une confirmation que la requête est prête (en se
servant de l’identifiant de la requête).
 Exécution de la requête (3 étapes)
1. L'identifiant de la requête à exécuter ainsi que les paramètres à utiliser
sont envoyés vers le serveur.
2. Le serveur exécute la requête demandée.
3. Le résultat de la requête est renvoyé au client
 Conclusion 1 : Lorsqu’on exécute une seule fois la requête, on a plus
d’étapes pour une requête préparée que pour une requête simple
(non préparée)
Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 81
3.1 Requêtes préparées : usage et utilité

 Cependant si l'on exécute plusieurs fois une requête, la tendance

s'inverse rapidement : on a plus d’étapes pour une requête simple que
pour une requête préparée (Conclusion 2)
 En effet, dans le cas d'une requête non préparée, toutes les étapes
doivent être répétées à chaque fois (sachant que la création du
plan d'exécution est l'étape la plus longue), alors que, pour une
requête préparée, seules les étapes d'exécution seront répétées.
 Il est donc intéressant, du point de vue des performances, de préparer
une requête lorsqu'elle va être exécutée plusieurs fois pendant la
même session
 Le fait que la requête soit compilée lors de sa préparation, et que le
plan d'exécution soit calculé également lors de la préparation et non
de l'exécution, explique pourquoi les paramètres peuvent uniquement
être des valeurs, et non des parties de requêtes comme des noms de
tables ou des mots-clés.
 En effet, il est impossible de créer le plan si l'on ne sait pas encore sur
quelles tables on travaillera ni quelles colonnes (et donc quels index)
seront utilisées.
Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 82
3.2 Procédures stockées

 Les procédures stockées sont disponibles depuis la version 5 de

MySQL. Elles permettent d'automatiser des actions qui peuvent être
très complexes.
 Une procédure stockée est en fait une série d'instructions
SQL désignée par un nom.

 Lorsqu’elle est créée, elle réside de manière permanente dans la

base de données au même titre qu'une table, par exemple. On peut
alors l'appeler par son nom à tout moment.

 Contrairement aux requêtes préparées, qui ne sont gardées en

mémoire que pour la session courante, les procédures stockées sont,
comme leur nom l'indique, stockées de manière durable, et font
bien partie intégrante de la base de données dans laquelle elles
sont enregistrées

Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 83

3.2 Procédures stockées : création

 La syntaxe de création d’une procédure stockée est la suivante

CREATE PROCEDURE nom_procedure ([parametre1 [, parametre2, ...]])
corps de la procédure;
 Les parenthèses après le nom de la procédure sont obligatoires.
 La procédure et les instructions se terminent par un délimiteur (point-
virgule par défaut).
 Lorsqu’il y a plusieurs instructions dans le corps de la procédure, on
l’entoure par BEGIN et END;
 Exemple 1 : avec une seule instruction (requête)
CREATE PROCEDURE afficher_races_requete()
SELECT id, nom, espece_id, prix FROM Race;
 Exemple 2 : bloc d’instructions
CREATE PROCEDURE afficher_races_requete()
BEGIN
SELECT id, nom, espece_id, prix FROM Race;
END;
 Ceci va générer une erreur car la procédure se termine avec le
premier point-virgule qui est aussi le délimiteur des instructions SQL.
Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 84
3.2 Procédures stockées : création

 Solution : Changer le délimiteur par défaut pour les procédures

stockées
 Syntaxe : DELIMITER caractère ; -- caractère de votre choix
 Exemple : DELIMITER | ;
 N’utilisez pas les caractères @ ou \ qui servent respectivement aux
variables utilisateur et à échapper les caractères spéciaux
 DELIMITER | -- On change le délimiteur
 CREATE PROCEDURE afficher_races ()
 BEGIN
 SELECT id, nom FROM Race; -- Cette fois, le ; ne nous embêtera pas
 END | -- Fin de CREATE PROCEDURE par le nouveau délimiteur
 La commande DELIMITER n’agit que pour la session courante
 Attention : Lors de l’utilisation de la procédure, les instructions à
l'intérieur du corps de la procédure seront bien délimitées par (;)
quelque soit le délimiteur défini.
 En effet, lors de la création d'une procédure, celle-ci est interprétée
par le serveur MySQL et le parseur des procédures stockées
interprétera toujours (;) comme délimiteur.
Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 85
3.2 Procédures stockées : utilisation

 Pour appeler une procédure stockée, il faut utiliser le mot-clé CALL

suivi du nom de la procédure appelée, puis de parenthèses (avec
éventuellement des paramètres).

 Exemple
 CALL afficher_races() | -- si le délimiteur est toujours | !!!

 Attention : Lors de l’utilisation de la procédure, les instructions à

l'intérieur du corps de la procédure seront bien délimitées par (;)
quelque soit le délimiteur défini par l’utilisateur.

 En effet, lors de la création d'une procédure, celle-ci est interprétée ou

parsée par le serveur MySQL et le parseur des procédures stockées
interprétera toujours (;) comme délimiteur. Il n’est pas influencé par la
commande DELIMITER

Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 86

3.2 Procédures stockées : paramètres

 Un paramètre peut être de trois sens différents : entrant (IN), sortant

(OUT) ou les deux (INOUT) :
 IN : il s'agit d'un paramètre dont la valeur est fournie à la procédure
stockée. Cette valeur sera utilisée pendant la procédure (pour un
calcul ou une sélection, par exemple).
 OUT : il s'agit d'un paramètre "sortant", dont la valeur sera établie au
cours de la procédure et qui pourra ensuite être utilisé en dehors de
cette procédure.
 INOUT : un tel paramètre sera utilisé pendant la procédure, verra
éventuellement sa valeur modifiée par celle-ci, et sera ensuite
utilisable en dehors.
 Lorsque l'on crée une procédure avec un ou plusieurs paramètres,
chaque paramètre est défini par trois éléments.
 Son sens : entrant, sortant, ou les deux. Si aucun sens n'est donné, il s'agira d'un IN
 Son nom : indispensable pour le désigner à l'intérieur de la procédure.
 on type : INT, VARCHAR(10), …

Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 87

3.2 Procédures stockées : paramètres

 Exemple
 DELIMITER | -- Facultatif si votre délimiteur est toujours |
 CREATE PROCEDURE afficher_race_selon_espece (IN p_espece_id INT)
 -- Définition du paramètre p_espece_id
 BEGIN
 SELECT id, nom, espece_id, prix FROM Race
 WHERE espece_id = p_espece_id; -- Utilisation du paramètre
 END |
 DELIMITER ; -- On remet le délimiteur par défaut si on veut
 Utilisation
 CALL afficher_race_selon_espece(1);
 SET @espece_id := 2;
 CALL afficher_race_selon_espece(@espece_id);
 Exemple 2
DELIMITER |
CREATE PROCEDURE compter_races_selon_espece (p_espece_id INT, OUT p_nb_races INT)
BEGIN
SELECT COUNT(*) INTO p_nb_races FROM Race WHERE espece_id = p_espece_id;
END |

Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 88

3.2 Procédures stockées : paramètres

 Dans ce dernier exemple on a un nouveau mot clé : INTO.

 Il permet d'assigner les valeurs sélectionnées par le SELECT à des
variables, au lieu de simplement afficher les valeurs sélectionnées.
 Pour pouvoir l'utiliser, il est nécessaire que le SELECT ne renvoie
qu'une seule ligne, et il faut que le nombre de valeurs sélectionnées
et le nombre de variables à assigner soient égaux
 Exemple pour deux valeurs
 SELECT id, nom INTO @var1, @var2
 FROM Animal
 WHERE id = 7;

 SELECT @var1, @var2;

 Le premier SELECT n’affiche rien mais met les résultats de la requête
dans les variables @var1 et @var2. Le deuxième SELECT les affiche.
 Utilisation ; CALL compter_races_selon_espece (2, @nb_races_chats);
 La variable @nb_races_chats contient maintenant le nombre de races
de chats. Il suffit de l'afficher pour vérifier.
 SELECT @nb_races_chats;
Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 89
3.2 Procédures stockées : suppression

 Pour supprimer une procédure, on utilise la commande DROP

 DROP PROCEDURE nom_procedure;

 Exemple
 DROP PROCEDURE afficher_races;

 Notons qu'il n'est pas possible de modifier une procédure directement.

 La seule façon de modifier une procédure existante est de la
supprimer puis de la recréer avec les modifications

 La commande ALTER PROCEDURE ne permet de changer ni les

paramètres ni le corps de la procédure.

 Elle permet uniquement de changer certaines caractéristiques de la

procédure

Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 90

3.2 Procédures stockées : avantages

 Les procédures stockées permettent de réduire les allers-retours

entre le client et le serveur MySQL : gain en performance.
 En effet, si l'on englobe en une seule procédure un processus
demandant l'exécution de plusieurs requêtes, le client ne communique
qu'une seule fois avec le serveur (pour demander l'exécution de la
procédure) pour exécuter la totalité du traitement.
 Elles permettent également de sécuriser une base de données. Par
exemple, il est possible de restreindre les droits des utilisateurs de
façon à ce qu'ils puissent uniquement exécuter des procédures.
 Finis donc les DELETE dangereux ou les UPDATE incontrôlés.
Chaque requête exécutée par les utilisateurs est créée et contrôlée
par l'administrateur de la base de données par l'intermédiaire des
procédures stockées.
 Cela permet ensuite de s'assurer qu'un traitement est toujours
exécuté de la même manière, quelle que soit l'application/le client
qui le lance.

Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 91

3.2 Procédures stockées: inconvénients

 Les procédures stockées ajoutent évidemment à la charge du

serveur de données. Plus on implémente de logique de traitement
directement dans la base de données, moins le serveur est disponible
pour son but premier : le stockage de données.
 Par ailleurs, certains traitements seront toujours plus simples et plus
courts à écrire (et donc à maintenir) s'ils sont développés dans un
langage informatique adapté. A fortiori lorsqu'il s'agit de traitements
complexes. La logique qu'il est possible d'implémenter avec
MySQL permet de nombreuses choses, mais reste assez
basique.
 Enfin, la syntaxe des procédures stockées diffère beaucoup d'un
SGBD à un autre. Par conséquent, si l'on désire en changer, il faudra
procéder à un grand nombre de corrections et d'ajustements.
 Conclusion : tout est finalement question d'équilibre. Il faut savoir
utiliser des procédures quand c'est utile, Il ne sert à rien d'en abuser.
Fotsing Talla Bernard, PhD Bases de Données : Aspects Avancés 92