存储过程中动态形成的SQL是否否定了存储过程的用途？

Question

我们现在有10到12年的旧项目.它使用的是我们现在转移到SQL2008的SQL2000.

在执行此任务时,我发现存储过程接受参数,然后将查询构造为字符串,然后使用EXEC执行命令.

CREATE PROCEDURE MyProc
  (@TableName varchar(255),
   @FirstName varchar(50),
   @LastName varchar(50))
AS

    -- Create a variable @SQLStatement
    DECLARE @SQLStatement varchar(255)

    -- Enter the dynamic SQL statement into the
    -- variable @SQLStatement
    SELECT @SQLStatement = "SELECT * FROM " +
                   @TableName + "WHERE FirstName = '"
                   + @FirstName + "' AND LastName = '"
                   + @LastName + "'"

    -- Execute the SQL statement
    EXEC(@SQLStatement)

这是一个糟糕的方法.这是否会破坏存储过程(预编译查询权益)的好处？

Answer 1

不,我认为存储过程的主要好处不再是它是"预编译"的事实(自2005年或更早,可能永远不会,除了非常高的音量调用).

有一个计划缓存,也可用于临时语句.

这个特殊的例子重新引入了注入漏洞,该漏洞可以自动执行:

CREATE PROCEDURE MyProc
  (@FirstName varchar(50),
   @LastName varchar(50))
AS
BEGIN
    SELECT * FROM TABLENAME
    WHERE FirstName = @FirstName
        AND LastName = @LastName
END

所有这些都是为了在表名上进行参数化.

存储过程的好处包括:

• 安全管理(能够独立于SELECT/INSERT/UPDATE控制EXEC权限)

• 访问协调(确保所有操作都以某种方式完成)

• 组织(能够以连贯的方式组织数据库的接口)

• 注射预防(存储过程总是参数,这确保来电者是不是能够让数据库的情况下,其很容易受到注入 - 请注意,SP的自身需要适当编写的,但客户端程序员将不能引进的注射,如果他们只有访问SP而不是表格)

• 系统清单(能够按名称分析和优化某些程序,能够拥有由存储过程组成的全面且记录良好的接口层)

SP中的动态SQL有它的位置,它可以否定一些东西 - 比如安全性(它启动一个新的链,因此需要在这里授予SELECT权限)和注入.执行计划缓存不是我会在列表中高举的.