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

【问题标题】：What are the downsides of creating SQL Server stored procedures in the following manner?以下列方式创建 SQL Server 存储过程的缺点是什么？
【发布时间】：2012-12-20 12:30:44
【问题描述】：

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

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

以下列方式创建脚本有什么缺点吗？

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

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

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

【问题讨论】：

根据您的表述方式，您可能会获得一些接近/主观的投票，无论如何这可能更适合 DBA，但我发现这是一个有趣的解决方案，可以解决我们在以前的公司遇到的问题.
好吧，我想我正在寻找合法的技术“缺点”......即DROP/CREATE而不是ALTERING有任何技术原因吗？ ALTERS 是否会对执行计划等产生任何影响...
很遗憾，SQL Server 已经有将近 20 年的历史了，但他们还没有开始实施“CREATE OR REPLACE”命令。
ALTER 不会影响 procs 的权限。如果 GRANTs 随着时间的推移而改变（他们为我们做了），那么你需要某种方式来解释这一点（这可能会更容易使用 drop/recreate？）我不知道性能/执行的任何原因为什么他们会有不同的表现。
@SWeko - 同意。 This is the 2nd most upvoted Connect Item request for SQL Server 于 2005 年发布。不知道为什么他们无法在此后的三个版本之一（2008、2008 R2 或 2012）中获得它

标签： sql sql-server tsql stored-procedures

【解决方案1】：

这里是 10 年的 SQL Server 开发人员/架构师，除了创建执行此操作的脚本的（相对轻微的）前期成本之外，我想不出任何不利因素。

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

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

【讨论】：

SQL Server 在创建 SP 时不编译计划。它在创建时被解析，但在第一次执行时编译并运行 ALTER PROC 无论如何都会使任何缓存的计划无效。
你是对的，当然。 :) 我可能不应该说“在创作时”。当应用程序框架在编译和链接时执行存储过程时，我遇到过这种情况，并且仅使用 DB2。正如我所说，我认为这是一种过分的谨慎——这确实是我能提出的唯一反对意见或警告。
感谢迪恩和马丁的反馈。 ~EoinCpan>