ソース管理のストアドプロシージャ/DBスキーマ

すべてをスクリプト化することを選択します。これには、すべてのストアドプロシージャとスキーマの変更が含まれます。 wysiwygツールや、凝った「同期」プログラムは必要ありません。

スキーマの変更は簡単です。必要なのは、すべてのスキーマとデータの変更を含め、そのバージョンの単一のファイルを作成して維持することだけです。これがバージョンxからx+1への変換スクリプトになります。次に、本番バックアップに対して実行し、それを「デイリービルド」に統合して、エラーなしで機能することを確認できます。後で記述されたSQLを壊してしまう可能性があるため、すでに記述されたスキーマ/データ読み込みSQLを変更または削除しないことが重要であることに注意してください。

-- change #1234
ALTER TABLE asdf ADD COLUMN MyNewID INT
GO

-- change #5678
ALTER TABLE asdf DROP COLUMN SomeOtherID
GO

ストアドプロシージャの場合、sprocごとに1つのファイルを選択し、ドロップ/作成フォームを使用します。すべてのストアドプロシージャは、展開時に再作成されます。欠点は、ソース管理外で変更が行われた場合、その変更が失われることです。同時に、これはどのコードにも当てはまりますが、DBA'aはこれを認識する必要があります。これにより、アップグレードで変更が失われるため、チーム外のユーザーがストアドプロシージャをいじくり回すのを防ぐことができます。

SQL Serverを使用すると、構文は次のようになります。

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[usp_MyProc]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
drop procedure [usp_MyProc]
GO

CREATE PROCEDURE [usp_MyProc]
(
    @UserID INT
)
AS

SET NOCOUNT ON

-- stored procedure logic.

SET NOCOUNT OFF

GO

あとは、すべての個々のファイルを照合し、更新のセット全体を含む新しいファイルを（単一のスクリプトとして）作成するユーティリティプログラムを作成するだけです。これを行うには、最初にスキーマの変更を追加してから、ディレクトリ構造を繰り返し、すべてのストアドプロシージャファイルを含めます。

すべてのスクリプトを作成することの利点として、SQLの読み取りと書き込みがはるかに上手になります。このプロセス全体をより複雑にすることもできますが、これは、特別なソフトウェアを使用せずにすべてのSQLをソース管理する方法の基本的な形式です。

補遺：リックは、DROP / CREATEを使用してストアドプロシージャのアクセス許可を失うことは正しいので、特定のアクセス許可を再度有効にする別のスクリプトを作成する必要がある場合があります。この許可スクリプトが最後に実行されます。私たちの経験では、ALTERとDROP/CREATEのセマンティクスに関する問題がさらに見つかりました。 YMMV