Le SQL dynamique et les procédures stockées sont deux des composants les plus importants de SQL Server. Dans cet article, nous examinerons les avantages et les inconvénients de chacun d'eux et quand les utiliser.
Performances
Tout le monde connaît la réponse à cette question. Les procédures stockées surpassent le SQL dynamique en termes de performances. Une procédure stockée est mise en cache dans la mémoire du serveur et son exécution est beaucoup plus rapide que le SQL dynamique. Si toutes les variables restantes sont maintenues constantes, la procédure stockée surpasse le SQL dynamique.
Séparation des préoccupations
En termes de séparation des préoccupations, les procédures stockées battent haut la main le SQL dynamique.
Les procédures stockées vous permettent de séparer la logique de votre base de données de votre logique métier. Ainsi, si une erreur se produit dans votre logique métier, vous n'avez qu'à modifier votre code d'application. Inversement, s'il y a un problème avec la logique de votre base de données, seule votre procédure stockée doit être modifiée. De plus, si une procédure stockée est mise à jour, le code de l'application n'a pas besoin d'être recompilé et déployé.
Si vous utilisez des requêtes SQL dynamiques dans votre code client, vous devrez mettre à jour le code de l'application si une erreur se produit dans la requête SQL. Cela signifie que vous devrez recompiler et déployer le code de l'application.
Trafic réseau
Les procédures stockées génèrent moins de trafic réseau que le SQL dynamique, car l'exécution d'une procédure stockée ne nécessite que le nom de la procédure et les paramètres (le cas échéant) à envoyer sur le réseau.
L'exécution de SQL dynamique nécessite l'envoi de la requête complète sur le réseau, ce qui augmente le trafic réseau, en particulier si la requête est très volumineuse.
Attaques par injection SQL
Les procédures stockées ne sont pas vulnérables aux attaques par injection SQL.
Les requêtes SQL dynamiques sont vulnérables aux attaques par injection SQL si les requêtes paramétrées ne sont pas utilisées, et les requêtes paramétrées ne peuvent pas être utilisées avec le SQL dynamique si un nom de table ou de colonne est passé en paramètre.
Dans ce cas, la solution consiste à utiliser la fonction de nom de code pour empêcher les attaques par injection SQL.
Réutilisabilité des plans de requête mis en cache
Les procédures stockées améliorent les performances de la base de données car elles permettent de réutiliser les plans de requête mis en cache. Dans le cas du SQL dynamique, vous devrez utiliser des requêtes paramétrées pour augmenter la réutilisabilité du plan de requête mis en cache. En l'absence de plans de requête paramétrés, le serveur SQL détecte automatiquement les paramètres et génère des plans de requête mis en cache, ce qui améliore les performances.
Il est pertinent de mentionner ici que seuls les systèmes OLTP bénéficient de la réutilisabilité du plan de requête mis en cache. Dans le cas des systèmes OLAP, le choix de l'optimiseur change, le système OLAP bénéficie du plan unique.
Entretien
Les procédures stockées avec SQL statique sont plus faciles à gérer. Par exemple, dans le cas de SQL statique dans une procédure stockée, les erreurs de syntaxe peuvent être interceptées avant d'être exécutées. Dans le cas de SQL dynamique à l'intérieur de procédures stockées, les erreurs de syntaxe ne peuvent pas être interceptées avant l'exécution de la requête.
De plus, les procédures stockées ressemblent davantage à des fonctions, elles sont définies une fois et peuvent ensuite être appelées n'importe où dans le script. Par conséquent, si vous souhaitez mettre à jour une procédure stockée, vous ne devez la mettre à jour qu'à un seul endroit. Toutes les parties de l'application appelant la procédure stockée auront accès à la version mise à jour. Cependant, un inconvénient est que ces parties d'application peuvent également être affectées là où vous ne voulez pas la procédure stockée mise à jour. En cas de SQL dynamique, vous devrez peut-être écrire un script SQL à plusieurs endroits, mais dans de tels cas, la mise à jour du script à un endroit n'affecte pas l'autre. Le choix entre l'utilisation d'une procédure stockée et d'un SQL dynamique dépend de la fonctionnalité de l'application.
Sécurité
Si plusieurs applications accèdent à la base de données, il est plus sûr d'utiliser des procédures stockées que SQL dynamique.
Les procédures stockées fournissent une couche de sécurité supplémentaire, tandis que le contexte utilisateur est le seul moyen de contrôler les autorisations sur les scripts SQL dynamiques. Dans l'ensemble, la sécurisation du SQL dynamique est laborieuse par rapport aux procédures stockées.
Identifier les dépendances
Dans une base de données relationnelle, les tables ont des dépendances sur d'autres tables de la base de données.
Considérez un scénario dans lequel vous souhaitez supprimer une table mais, avant cela, vous souhaitez connaître toutes les dépendances de la table. Ou en termes simples, vous souhaitez rechercher les requêtes qui accèdent à la table que vous souhaitez supprimer. Dans ces cas, vous pouvez utiliser la procédure stockée sp_depends.
Cependant, sp_depends ne peut détecter que les dépendances où le SQL statique est utilisé dans une procédure stockée. Dans le cas où SQL dynamique dépend d'une table, cette dépendance ne peut pas être détectée par la procédure stockée sp_depends. Voyons cela en action à l'aide d'un exemple simple.
Préparation des données factices
Créons des données factices pour aider à expliquer le concept de dépendances en SQL statique et dynamique.
CREATE DATABASE deptest;USE deptestCREATE TABLE étudiant( Id int clé primaire d'identité, nom VARCHAR(50) NOT NULL, sexe VARCHAR(50) NOT NULL, âge int)INSERT INTO studentVALUES('James', 'Male', 20 ),('Helene', 'Femme', 20),('Sofia', 'Femme', 20),('Ed', 'Homme', 20),('Ron', 'Femme', 20)
Nous avons maintenant une base de données de test contenant une table et des données de test. Créons maintenant deux procédures stockées qui accèdent à la table des étudiants.
La première procédure stockée utilise du SQL statique pour récupérer tous les enregistrements de la table des étudiants :
USE deptestGOCREATE PROC spStatProcASBEGIN SELECT * FROM étudiantEND
Exécutez le script ci-dessus. Ce script crée une procédure stockée "spStatProc" dans la base de données deptest.
Créons une autre procédure stockée contenant du SQL dynamique qui récupère tous les enregistrements de la table des étudiants.
USE deptestGOCREATE PROC spDynProcASBEGIN DECLARE @query NVARCHAR(100) SET @query ='SELECT * FROM étudiant' EXECUTE sp_execute @query END
Ce script crée une procédure stockée "spDynProc" dans la base de données deptest. Cette procédure stockée utilise une instruction SQL dynamique pour récupérer tous les enregistrements de la table des étudiants.
Nous avons maintenant deux procédures stockées qui dépendent de la table des étudiants. L'un d'eux contient du SQL statique et l'autre du SQL dynamique.
Cependant, si vous exécutez la procédure stockée sp_depends et que vous lui transmettez la table des étudiants en tant que paramètre, vous verrez qu'elle ne récupérera que la procédure stockée "spStatProc". C'est parce qu'il contient du SQL statique. La procédure stockée "spDynProc" sera ignorée car elle contient du SQL dynamique.
Exécutez le script suivant.
UTILISER deptestGOEXECUTE sp_depends étudiant
Il obtiendra la sortie suivante :
[identifiant de table=40 /]
Vous pouvez voir que sp_depends n'a pas pu signaler la dépendance "spDynProc" et n'a signalé que "spStatProc".
Complexité
Les procédures stockées peuvent devenir extrêmement complexes si vous utilisez un grand nombre de filtres et qu'il existe plusieurs clauses AND et OR entre les filtres. D'autre part, en utilisant SQL dynamique, vous pouvez générer dynamiquement des clauses WHERE en fonction du type de filtres. Cela fait du SQL dynamique le meilleur choix si vous souhaitez implémenter une logique extrêmement complexe.
Conclusion
Dans l'ensemble, la procédure stockée surpasse le SQL dynamique dans presque tous les aspects. Ils sont plus rapides, sécurisés et faciles à entretenir, et nécessitent moins de trafic réseau. En règle générale, les procédures stockées doivent être utilisées dans les scénarios où vous n'avez pas à modifier vos requêtes et où vos requêtes ne sont pas très complexes. Toutefois, si vous modifiez fréquemment les noms de table, les noms de colonne ou le nombre de paramètres dans votre requête, Dynamic SQL est le meilleur choix en raison de sa stratégie de mise en œuvre plus simple.
Liens utiles
- SQL dynamique contre procédures stockées
- Ne craignez pas le SQL dynamique
- Création de procédures stockées hautes performances
- Cours sur les procédures stockées
