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...
DROP および CREATE に対する CREATE および ALTER の利点は、ストアド プロシージャが 1 回しか作成されないことです。一度作成されると削除されることはないため、アクセス許可が削除されて再作成されない可能性はありません。
完璧な世界では、ストアド プロシージャのアクセス許可はデータベース ロールを介して適用されるため、ストアド プロシージャを削除して再作成した後に簡単に再適用できます。しかし実際には、数年後に他のアプリケーションが同じストアド プロシージャを使用し始めたり、善意の DBA が何らかの理由で新しいアクセス許可を適用したりすることがよくあります。そのため、DROP と CREATE を使用すると、数年後にアプリケーションが壊れる傾向があることがわかりました (そして、何も知らない他人のアプリケーションの場合は常に悪化します)。CREATE と ALTER は、これらの問題を回避します。
ちなみに、ダミーの create ステートメント "CREATE PROC dbo.MyProc AS SELECT 0" は、任意のストアド プロシージャで機能します。実際のストアド プロシージャがパラメーターを持つか、ALTER PROC ステートメントですべて指定できる複数の列を含むレコードセットを返す場合。CREATE PROC ステートメントは、可能な限り単純なストアド プロシージャを作成するだけです。(もちろん、CREATE PROC ステートメントのストアド プロシージャの名前は、ストアド プロシージャの名前と一致するように変更する必要があります)