动态SQL vs参数化查询
该存储过程是否被视为动态SQL或参数化查询?动态SQL vs参数化查询
CREATE PROCEDURE [dbo].[my_dodgy_sp]
@varchar1 varchar(50),
@varchar2 varchar(50)
AS
BEGIN
...
EXEC [dbo].[my_really_special_sp] @varchar1 @varchar2;
END
在顶部的樱桃额外的巧克力甜甜圈如果你能告诉我这是否是动态/参数化:
CREATE PROCEDURE [dbo].[my_super_dodgy_sp]
@varchar1 varchar(50),
@varchar2 varchar(50),
@stored_procedure_name sysname
AS
BEGIN
...
EXEC @stored_procedure_name @varchar1 @varchar2;
END
“动态SQL”是指以编程方式构建SQL查询字符串。如添加联接,建立where子句等。
参数化查询是包含变量的SQL查询字符串,其值由SQL查询字符串单独提供。
您的示例都不符合这些描述,因为它们都是存储过程中的简单T-SQL调用。
它可能看起来迂腐,但如果你的应用程序调用'EXEC [dbo].[my_really_special_sp] @varchar1 @varchar2'
,然后即是一个参数化查询。
如果你的SP调用sp_executesql 'EXEC [dbo].[my_really_special_sp] @var1 @var2', @var1 = 1, @var2 = 10
然后...
-
sp_executesql
是T-SQL调用 -
'EXEC [dbo].[my_really_special_sp] @var1 @var2'
是你的参数化查询 -
@var1 = 1, @var2 = 10
是你的参数
的重要的一点是你的例子是SP中的预编译语句。我试图解释的示例是字符串,它们被传递给SQL Server以解析,编译和执行。
如果该字符串是以编程方式逐个构成的,则它是动态sql。
如果该字符串包含单独提供的变量引用,则它将被参数化。
我希望有帮助,但我可以看到它可能看起来很主观。
至于你的编程风格。您的第二个SP存在轻微的“漏洞”,因为如果用户有权访问它,即使该用户本身不能正常访问,他们也可以访问具有相同签名的所有其他SP。这可能是故意的,并且/或者您可以验证@spname参数来关闭此漏洞。除此之外,我没有看到任何可能存在的错误。
辉煌,我喜欢迂腐,它解决了很多困惑:)这是迄今为止最清晰的差异描述。 – icc97 2012-01-07 02:11:51
EXEC [dbo].[my_really_special_sp] @varchar1 @varchar2;
是不是参数化查询,它是一个存储的正常通话程序。
如果这将导致参数化查询,则取决于[my_really_special_sp]
的内容。
请提供更多信息,我想帮助你更多。
感谢@dknaack,对于模糊不清,但我试图弄清楚我的编程风格是否存在任何严重问题。一般my_really_special_sp会像'UPDATE [my_table] SET [field1] = @ varchar1 WHERE [field2] = @ varchar2' – icc97 2012-01-07 01:24:06
我有一个版本的工作是和没有操纵。是'UPDATE [my_table] SET [field1] = @ varchar1 WHERE [field2] = @ varchar2'参数化查询? – icc97 2012-01-07 01:34:18
你应该使用第一种方法,以获得更好的可读性,更好的测试和最重要的事情......更少的调用(更好的性能)。 – dknaack 2012-01-07 01:37:06
为了让超级傻瓜sp更少,你可以添加一些验证来确保@spname是'合法的'。 – MatBailie 2012-01-07 01:45:00
这是我困惑的地方。由于超级dodgy只是使用参数,这可能是一个参数化查询,在这种情况下,你不能注入SQL代码。所以它根本就不狡猾,你不需要验证。 – icc97 2012-01-07 01:52:07
你不能用'EXEC @sp @ param'注入代码。您只能提供对不同SP的引用。这是微妙的不同。我不完全同意dknaack的回答,所以我加了我自己的。我希望它可以帮助:) – MatBailie 2012-01-07 02:02:26