2010-07-15 5 views
1

J'utilise SQL Server 2008 Enterprise sur Windows Server 2008 Enterprise. Dans une procédure stockée, nous pouvons exécuter une instruction SELECT directement. Et il pourrait aussi être exécuté de cette nouvelle façon, je me demande quelle méthode est la meilleure, et pourquoi?Procédure stockée Problème d'instruction SQL SELECT

Nouvelle méthode,

declare @teststatement varchar(500) 

set @teststatement = 'SELECT * from sometable' 

print @teststatement 

exec (@teststatement) 

Méthode traditionnelle,

SELECT * from sometable 

salutations George

+5

Vous pourriez envisager d'augmenter votre cote d'acceptation. –

+2

Etre nitpicky ici: ces choses sont appelées "magasin * D * procédures" - ils sont stockés dans SQL Server - pas "procédures de stockage" - ils n'ont rien à voir avec un "magasin" ... –

Répondre

2

FYI: ce n'est pas une nouvelle méthode, elle s'appelle Dynamic SQL.

SQL dynamique sont préférés lorsque nous devons définir ou concaténer certaines valeurs dans les instructions SQL.

Les instructions sql traditionnelles ou normales sont recommandées car les procédures stockées sont respectées. Conforme à la première exécution"Stored Procedure are Compiled on First Run" , le plan d'exécution des instructions est en cours de création au moment de la compilation.

Les SQL dynamiques sont ignorés lors de la création de plans d'exécution, car ils sont considérés comme des chaînes (VARCHAR ou NVARCHAR comme déclaré).

Reportez-vous ci-dessous des articles pour plus de détails sur requête dynamique et procs stockées
Introduction to Dynamic SQL Part 1
Introduction to Dynamic SQL Part 2
Everything you wanted to know about Stored Procedures

+0

Vous voulez dire dans mon scénario, (1) aucun plan de requête n'est créé pour l'instruction selecgt? (2) Ou plan de requête est créé, mais pas mis en cache? – George2

+1

"aucun plan de requête n'est créé pour l'instruction select" Lisez l'article mentionné "Intro to Dynamic SQL Part 1" .. faites défiler vers le bas et vous verrez ce paragraphe "L'inconvénient de cette méthode est double. , votre procédure stockée ne peut pas mettre en cache le plan d'exécution pour cette requête dynamique.Pour les requêtes complexes, vous perdrez l'amélioration des performances que vous obtenez habituellement avec les procédures stockées. " – CoderHawk

+1

vous devez mettre un peu d'effort pour apprendre de nouvelles choses: p – CoderHawk

1

La méthode traditionnelle est plus sûr, parce que la requête est analysée lorsque vous enregistrez. La requête dans la méthode 'exec' n'est pas analysée et peut contenir des erreurs.

+0

Merci! 1. Erreur vous voulez dire quoi, pouvez-vous me montrer un échantillon? 2. Avez-vous plus de document pour faire une référence, je veux en savoir plus sur vos points comme ceci - "La méthode traditionnelle est plus sûre, parce que la requête est analysée quand vous l'enregistrez.". – George2

+0

3."analysé quand vous l'enregistrez" - analyser que vous voulez dire quand enregistrer la procédure de magasin? Donc, analysé avant d'exécuter la déclaration SQL? – George2

+1

Non, la validité est vérifiée par SQL Server. Tout comme le bouton "Vérifier la requête" dans votre éditeur. Et je ne l'ai pas obtenu d'un livre, mais de l'expérience. – Prutswonder

0

La "nouvelle" façon, comme mentionné, n'a rien à voir avec SQL 2008. EXEC a été disponible pour un certain temps. C'est aussi - dans la plupart des cas - une très mauvaise idée.

Vous perdez le paramétrage, ce qui signifie que vous êtes maintenant vulnérable à SQL Injection. C'est moche et sujet aux erreurs. C'est moins efficace. Et il crée une nouvelle portée d'exécution - ce qui signifie qu'il ne peut pas partager les variables, les tables temporaires, etc. - à partir de son appel stocké proc.

sp_executesql est une autre méthode (et préférée) d'exécution de SQL dynamique. C'est ce que vos applications clientes utilisent, et il supporte les paramètres - ce qui résout le problème le plus flagrant d'EXEC. Cependant, il a également des cas d'utilisation très limités dans un proc stocké. A propos de la seule utilisation de rachat est lorsque vous avez besoin d'un nom de table ou de colonne dynamique. T-SQL ne supporte pas une variable pour cela - vous devez donc utiliser sp_executesql. Le nombre de fois que vous devez ou devez faire cela est très bas.

Conclusion: vous feriez mieux d'oublier que vous en avez déjà entendu parler.

Questions connexes