3. Le résultat de la requête est renvoyé au client.
On a donc plus d'étapes pour une requête préparée, que pour une requête non préparée (8 contre 5). Du moins, lorsque l'on
exécute une seule fois la requête. Car si l'on exécute plusieurs fois une requête, la tendance s'inverse rapidement : 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, seule les étapes d'exécution seront répétées.
Il est donc intéressant, d'un 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 (je vous rappelle que les requêtes préparées sont supprimées à la fin de la 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.
En résumé
Les variables utilisateur sont, comme leur nom l'indique, des variables définies par l'utilisateur.
Les variables utilisateur sont précédées du caractère @ et peuvent être définies par la commande SET ou l'opérateur
d'assignation :=.
Une requête préparée est un modèle de requête auquel on donne un nom, pour pouvoir l'appeler à loisir, en lui passant
éventuellement des paramètres, représentés dans la requête préparée par le caractère ?.
Lorsque l'on prépare une requête, celle-ci doit être représentée par une chaîne de caractères, qui peut être préalablement
stockée dans une variable utilisateur.
Les requêtes préparées permettent de se protéger des injections SQL.
Lorsqu'une requête doit être exécutée plusieurs fois, la préparer peut permettre de gagner en performance.
Partie 5 : Sécuriser et automatiser ses actions
264/414
www.openclassrooms.com
On a donc plus d'étapes pour une requête préparée, que pour une requête non préparée (8 contre 5). Du moins, lorsque l'on
exécute une seule fois la requête. Car si l'on exécute plusieurs fois une requête, la tendance s'inverse rapidement : 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, seule les étapes d'exécution seront répétées.
Il est donc intéressant, d'un 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 (je vous rappelle que les requêtes préparées sont supprimées à la fin de la 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.
En résumé
Les variables utilisateur sont, comme leur nom l'indique, des variables définies par l'utilisateur.
Les variables utilisateur sont précédées du caractère @ et peuvent être définies par la commande SET ou l'opérateur
d'assignation :=.
Une requête préparée est un modèle de requête auquel on donne un nom, pour pouvoir l'appeler à loisir, en lui passant
éventuellement des paramètres, représentés dans la requête préparée par le caractère ?.
Lorsque l'on prépare une requête, celle-ci doit être représentée par une chaîne de caractères, qui peut être préalablement
stockée dans une variable utilisateur.
Les requêtes préparées permettent de se protéger des injections SQL.
Lorsqu'une requête doit être exécutée plusieurs fois, la préparer peut permettre de gagner en performance.
Partie 5 : Sécuriser et automatiser ses actions
264/414
www.openclassrooms.com