以下列方式创建SQL Server存储过程的缺点是什么?

Eoi*_*ell 5 sql t-sql sql-server stored-procedures

我们将所有数据库对象检入源代码控制作为可重新运行的脚本(视图,函数,触发器和存储过程等...)

在部署时,我们需要确保所有脚本都可以重新运行和重复,以便创建/更新存储过程到最新版本.

以下列方式创建脚本是否有任何缺点.

IF NOT EXISTS 
(
    SELECT      * 
    FROM        INFORMATION_SCHEMA.ROUTINES
    WHERE       ROUTINE_SCHEMA = 'dbo'
    AND         ROUTINE_NAME = 'MyStoredProcedure'
)
BEGIN
    EXEC ('CREATE PROCEDURE [dbo].[MyStoredProcedure] AS SELECT 1')
    -- ALSO DO ANY INITIAL GRANT PRIVILEGE SCRIPTING HERE
END
GO
ALTER PROCEDURE [dbo].[MyStoredProcedure] (
    @param1 INT,
    @param2 NVARCHAR(50) = 'Default String'
)
AS
BEGIN
    -- DO SOMETHING WITH @param1 AND @param2
    SELECT 1;
END
GO
Run Code Online (Sandbox Code Playgroud)

本质上,脚本检查对象是否存在于相关系统视图中,如果它不存在,则某些动态sql将其创建为存根,以解决CREATE PROCEDURE/GO条件块中不允许的语句问题.然后它通过一个应用脚本的实际功能ALTER.

所以这些好处对我来说是显而易见的,我只是想知道这样做是否有任何缺点......除了编写稍微冗长的脚本的轻微开销.

小智 2

我是一名拥有 10 年 SQL Server 开发人员/架构师经验的人,除了创建执行此操作的脚本的(相对较小的)前期成本之外,我想不出任何缺点。

如果您担心在创建时编译为微不足道的计划在过程更改时不会重新编译,您可以为每个计划添加对 SP_RECOMPILE 的显式调用,但我在 SQL Server 中从未遇到过此问题(我遇到过它与 DB2),所以我认为这是过度谨慎。

这是一个有趣且我认为有用的方法。