Par exemple, LINQ to SQL envoie ce qui suit:
exec sp_executesql
N'SELECT [t0].[HomeID],
[t0].[Bedrooms],
[t0].[ImageURL],
[t0].[Price],
[t0].[Available],
[t0].[Description]
FROM
[dbo].[Homes] AS [t0]
WHERE
([t0].[Description] LIKE @p0) AND
([t0].[Available] = @p1) AND
([t0].[Price] >= @p2) AND ([t0].[Price] <= @p3)
ORDER BY
[t0].[Price] DESC',
N'@p0 nvarchar(4000),@p1 int,@p2 int,@p3 int',
@p0=N'%private%',
@p1=1,
@p2=200000,
@p3=750000
6 Réponses :
sp_executesql est préféré sur l'exécution car il prend en charge la substitution des paramètres et tend à fonctionner plus efficacement.
Exécuter est tout aussi paramétralisable, de sorte que le paramétrage n'est donc pas. Quelles données indiquent qu'il effectue "plus efficacement" son au moins le même coût.
Il peut avoir été plus techniquement correct de dire la substitution de paramètres plutôt que le paramétrage, quant à l'efficacité, je vous invite à consulter le lien suivant. msdn.microsoft.com/en-us/library/ms175170.aspx
msdn.microsoft.com/en-us/library/ms175580.aspx En tant qu'informations complémentaires sur l'exécution soutenant les mêmes stratégies de mise en cache de relevé paramétré.
L'article parle de l'énoncé d'exécution SQL. L'OP se demande pourquoi SP_Executesql est envoyé plutôt que d'envoyer directement l'instruction "INTERNET" (paramètres et tous).
Oui, je suppose que je devrais qualifier le mien un peu mieux aussi :) SqlexecDirect via OLEDB / ODBC est simplement paramétralisable. Sauf s'il y avait plus qu'une seule déclaration est envoyée - il ne semble pas avoir de sens.
Cette notation permet de réutiliser la relève TSQL compilée d'exécution avec différents paramètres; c'est-à-dire que la déclaration ne sera compilée qu'une fois, ce qui améliore l'efficacité.
Exécuter utilise le même cache d'instruction avec des requêtes paramétrées.
De cette façon, cela est plus sûr contre l'injection SQL.
Ceci est, au moins partiellement, de sorte que vous obtenez une réutilisation du plan de requête. Il pourrait mettre les paramètres en ligne, ce qui signifie que chaque fois que vous exécutez la requête avec différents paramètres, l'analyseur le voit comme une requête différente et la répare. Mais comme il est exécuté de cette façon, le plan de requête est mis en cache et il peut simplement brancher les nouvelles variables chaque fois que vous l'exécutez.
Une chose à noter est qu'il fournit également une protection contre Injection SQL en raison du paramétrage. Ne peut pas vraiment se plaindre de celui-ci ...
Pas selon ce lien: msdn.microsoft.com/en-us/Library/ MS188001.aspx - "Les instructions TRAND-SQL compilées du temps peuvent exposer des applications à des attaques malveillantes, telles que l'injection SQL."
Ce n'est pas une raison d'utiliser sp_executesql tho '. Le paramétrage est disponible sur les appels sqlexecDirect via OLE / DB et ODBC.
@Adamski - Bien sûr, il fait .. msdn.microsoft.com/en-us /Library/bb386929.aspx . "Linq à SQL évite une telle injection en utilisant SQLParameter dans des requêtes."
C'est une excellente question.
Ce n'est pas vraiment la réponse, mais une exploration du raisonnement déjà donné par d'autres réponses. N'hésitez pas à mettre à jour cette "réponse"
La réponse évidente aurait été " Syntaxe et détails dans cet article msdn article ...
Réclamations de performance Je doute sans données car le cache semble être le même pour les requêtes directes et sp_execsql'd.
Donc si ce n'est pas ceux - qu'est-ce que c'est? cache de requête paramétrée ". Cependant, les paramètres pourraient aussi facilement être liés lorsque l'instruction a été exécutée directement et est toujours mise en cache.
Je ne pense pas que ce soit une solution de performance. Les plans d'exécution en SQL sont mis en cache même pour des requêtes directes.
Je pense que c'est une solution de sécurité pour l'injection SQL.
Toutefois, si vous essayez d'utiliser des traces qui utilisent LINQ vers SQL dans le conseiller de syntonisation du moteur de base de données, SP_Execute n'est pas interprété par le conseiller de syntonisation, je voudrais l'éteindre. L'injection SQL peut également être détectée dans les instructions / framework LINQ vers SQL (le code) pourriez-vous même essayer d'envoyer des données non valides à SQL.
OP Vous devriez clarifier ce que vous voulez dire un peu - je suppose que vous regardez via SQL Profiler et voir les appels qui coulent. J'introduit votre question comme "Pourquoi L2 utilise-t-il SP_EXecutesQL plutôt que d'envoyer directement les énoncés contenus".