Question

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

例如，如果我更改存储过程，部署脚本将生成类似这样的内容......

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。

通过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的优点是存储的proc只创建一次。一旦创建，它永远不会被删除，因此没有权限被删除而不能重新创建。

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

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

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

1 个答案: