有没有办法让Visual Studio 2010数据库项目使用DROP和CREATE而不是ALTER for DML

Question

在为Visual Studio 2010 SQL数据库项目构建部署脚本时，是否有任何方法可以指示进程对存储过程和其他DML使用DROP和CREATE，而不是总是对它们进行ALTER？

例如，如果我更改存储过程，部署脚本将生成如下内容。。。

ALTER PROCEDURE MyProc
AS
SELECT yadda...

我希望部署脚本创建这样的东西，而不是

IF EXISTS MyProc
  DROP MyProc
CREATE PROCEDURE MyProc
AS 
SELECT yadda....

它将使版本控制的升级脚本更易于管理，并且部署的更改将执行得更好。同样，若这不可能，一种至少用ALTER发出RECOMPILE的方法会有所帮助。

这个问题提出了一些类似的问题，但我不希望表出现这种行为，只是DML。

Answer 1

我对数据库项目不够熟悉，无法回答是否可以执行DROP和CREATE。然而，总的来说，我发现CREATE和ALTER比DROP和CREATE更好。

我所说的CREATE和ALTER的意思是：

IF NOT EXISTS (SELECT 1 FROM INFORMATION_SCHEMA.ROUTINES 
                WHERE ROUTINE_NAME = 'MyProc'
                AND ROUTINE_TYPE = 'PROCEDURE')
BEGIN;
    -- CREATE PROC has to be the first statement in a batch so 
    --  cannot appear within a conditional block.  To get around 
    --  this, make the statement a string and use sp_ExecuteSql.
    DECLARE @DummyCreateText NVARCHAR(100);
    SET @DummyCreateText = 'CREATE PROC dbo.MyProc AS SELECT 0;';
    EXEC sp_ExecuteSql @DummyCreateText;
END;
GO
ALTER PROCEDURE dbo.MyProc  
AS
    SELECT yadda...

CREATE和ALTER相对于DROP和CREATE的优势在于，存储过程只创建一次。一旦创建，它就永远不会被删除，因此权限就不会被删除或重新创建。

在一个完美的世界里，对存储过程的权限将通过数据库角色应用，因此在删除和重新创建存储过程后很容易重新应用它们。然而，在现实中，我经常发现，几年后，其他应用程序可能会开始使用相同的存储过程，或者出于某种原因，善意的DBA可能会应用新的权限。所以我发现DROP和CREATE往往会导致应用程序在几年后崩溃（当你对别人的应用程序一无所知时，情况总是更糟）。CREATE和ALTER避免了这些问题。

顺便说一句，伪create语句"create PROC dbo.MyProc AS SELECT 0"适用于任何存储过程。如果实际存储过程将具有参数或返回具有多个列的记录集，这些列都可以在ALTER PROC语句中指定。CREATE PROC语句只需要创建尽可能简单的存储过程。（当然，CREATE proc语句中存储的proc的名称需要更改，以匹配存储的proc的名称）