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

Question

当为Visual Studio 2010 SQL数据库项目构建部署脚本时，有没有什么方法可以指示进程使用DROP和CREATE对于存储过程和其他DML而不是总是改变它们？

举个例子，如果我更改存储过程，部署脚本会产生这样的事情...

ALTER PROCEDURE MyProc 
AS 
SELECT yadda... 

我想部署脚本这样反而

IF EXISTS MyProc 
    DROP MyProc 

CREATE PROCEDURE MyProc 
AS 
SELECT yadda.... 

创造的东西

这将使版本控制的升级脚本更易于管理，并且部署的更改将表现更好。另外如果这是不可能的，至少用ALTER发布RECOMPILE的方法会有所帮助。

This问题问的东西似乎相似，但我不希望这种行为的表，只是DML。

Answer 1

我对数据库项目不够熟悉，无法给出关于是否可以执行DROP和CREATE的答案。但是，通常我发现CREATE和ALTER比DROP和CREATE更好。

通过创建和更改我的意思是这样的：

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... 

的是，在存储过程只创建一次创建和更改过DROP和创造了有利条件。一旦创建，它永远不会被丢弃，因此不会有权限丢弃和重新创建的机会。

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

顺便说一下，dummy create语句，“CREATE PROC dbo.MyProc AS SELECT 0”，适用于任何存储过程。如果真正的存储过程将有参数或返回一个记录集，并且可以在ALTER PROC语句中指定多个列。 CREATE PROC语句只需创建最简单的存储过程即可。 （当然，CREATE PROC语句中存储过程的名称将需要更改以匹配存储过程的名称）