Question

此存储过程是否被视为动态SQL或参数化查询？

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

Answer 1

EXEC [dbo].[my_really_special_sp] @varchar1 @varchar2;

不是Parameterised查询，它是存储过程的正常调用。

如果这会导致参数化查询，则取决于[my_really_special_sp]的内容。

请提供更多信息，我想为您提供更多帮助。

Answer 2

“动态SQL”是指以编程方式构建SQL查询字符串。比如添加连接，构建where子句等等。

参数化查询是包含变量的SQL查询字符串，其值与SQL查询字符串分开提供。

您的示例都不符合这些描述，因为它们都是存储过程中的简单T-SQL调用。

它可能看起来很迂腐，但如果您的应用程序调用{{1}}，则是参数化查询。

如果您的SP拨打'EXEC [dbo].[my_really_special_sp] @varchar1 @varchar2'，那么......

sp_executesql 'EXEC [dbo].[my_really_special_sp] @var1 @var2', @var1 = 1, @var2 = 10是T-SQL调用

sp_executesql是您的参数化查询

'EXEC [dbo].[my_really_special_sp] @var1 @var2'是您的参数

重要的是，您的示例是SP中的预编译语句。我试图解释的例子是 strings ，它们被传递给SQL Server进行解析，编译和执行。

如果该字符串是以编程方式逐个编写的，那么它就是动态的sql。

如果该字符串包含单独提供的变量引用，则进行参数化。

我希望这有所帮助，虽然我可以看出它看起来似乎是主观的。

至于你的编程风格。您的第二个SP有一个轻微的“漏洞”，因为如果用户有权访问它，他们可以访问具有相同签名的所有其他SP，即使该用户本身通常不具有访问权限。这可能是有意的，和/或您可以验证@spname参数以关闭漏洞。除此之外，我无法看到任何可能出现故障的事情。

动态SQL与参数化查询

2 个答案: