J'ai entendu quelqu'un dire que vous ne vouliez pas utiliser Dynamic SQL. Pouvez-vous donner un exemple concret ou un exemple concret? Personnellement, je le code plusieurs fois dans ma base de données. Je pense que c'est OK parce que c'est la flexibilité. Ma conjecture concerne l'injection SQL ou les performances. Rien d'autre?
Réponses:
Il n'y a rien de mal à utiliser SQL dynamique si vous le devez. En fait, dans certaines circonstances, c'est la seule option que vous avez. Il s'agit plus d'une recommandation de ne pas l'utiliser, car cela peut entraîner une injection SQL si votre entrée n'est pas filtrée, et oui, l'utilisation de SQL dynamique dans des modules qui sont souvent appelés peut nuire à ses performances.
Je ne pense pas qu'il existe un exemple concret en soi, mais je dirais ceci: essayez de réaliser ce que vous êtes après avoir utilisé des requêtes et des déclarations régulières en premier - seulement une fois que vous avez épuisé toutes les autres voies, faites-le dynamiquement. N'oubliez pas que l'exécution d'une chaîne SQL dynamique se fait dans une session utilisateur distincte au module qui l'appelle - vous pouvez donc rencontrer des problèmes d'autorisations où vous n'en attendez pas.
Si vous vous inquiétez de la performance; Essaye-le. Si vous vous inquiétez pour la sécurité; valider votre saisie. Il n'y a pas de bien ou de mal - seulement que vous utilisez votre meilleur jugement sur la base des informations et des outils dont vous disposiez à l'époque.
Dynamic SQL est un outil. Et comme outil, il a des applications - pour les travaux administratifs, c'est une bénédiction, par exemple.
Pas si bon sur SP utilisé par les applications, surtout si vous ne gérez pas le paramétrage du code généré (les dernières versions de SQL Server ont réduit les problèmes, mais restent valables).
Je n'entrerai pas en détail ici, donc je recommanderai un excellent article sur les problèmes de Dynamic SQL: The Curse and Blessings of Dynamic SQL par MVP Erland Sommarskog.
C'est comme la plupart des fonctionnalités dbms, si vous l'utilisez dans la bonne situation, il fait bien son travail, dans la mauvaise situation, il le fait mal.
Avantages: Certaines choses ne peuvent tout simplement pas être faites sans cela. En règle générale, je n'ai trouvé que cela pour le travail administratif et non pour le code d'application. Certaines commandes système ne permettent pas d'utiliser des paramètres en entrée. Ainsi, par exemple, si j'ai besoin d'exécuter quelque chose via un sproc sur chaque base de données, sur de nombreuses instances avec des bases de données inconnues, et que la commande n'accepte pas de paramètres, je résous généralement cela via SQL dynamique. Cependant, c'est plus une chose dans Sybase ASE que MSSQL.
Inconvénients: je ne m'y attarderai pas beaucoup, car je pense que nous le savons tous déjà, mais il peut y avoir un risque pour l'injection SQL si elle est utilisée incorrectement. Le plus important pour moi est que la requête sera traitée comme ce qu'elle est, une requête ad hoc unique et ne fera pas partie du plan de requête compilé. Pour quelque chose qui s'exécute occasionnellement, ce n'est pas grave. Pour quelque chose qui est exécuté des centaines de fois par minute et qui va avoir beaucoup de sql unique, cela générerait beaucoup de nouveaux plans de requête potentiellement inutiles, consommant des cycles et raccourcissant la durée de validité du cache du plan.
N'utilisez pas Dynamic SQL.
99% du temps Dynamic SQL est utilisé en raison du manque de connaissances sur la façon d'utiliser les paramètres facultatifs dans les procédures stockées, le reste 1% du temps est utilisé pour créer une requête très complexe pour un rapport que le client ne comprend pas même. La malédiction et les bénédictions de Dynamic SQL ne montre pas pourquoi ce serait une bonne idée de l'utiliser, mais suggère simplement qu'il est problématique car il augmente la complexité du débogage, de la maintenance, sans parler des risques de sécurité de SQL Injection, performances médiocres non pas parce que le cache mais les mauvaises pratiques qui l'accompagnent comme l'utilisation de tables temporaires et de curseurs qui bien sûr sont paresseux et naïfsprogrammeur abuserait de. Il n'y a pas de flexibilité pour écrire des requêtes de cette façon, SQL est un langage déclaratif et devrait être traité comme tel.
La paresse est la racine de tout mal.
Paradoxalement, cette réponse va se classer parmi les plus défavorisées .