ソース管理のストアドプロシージャ/ DBスキーマ
選択したソース管理システムでストアドプロシージャとデータベーススキーマを追跡していますか？
変更（テーブルの追加、ストアドプロシージャの更新）を行う場合、どのようにして変更をソース管理に取り込みますか？
私たちは仕事でSQL Serverを使用しており、バージョン管理にdarcsを使い始めましたが、一般的な戦略や便利なツールに興味があります。
編集：すごい、すばらしい提案をありがとう、みんな！ 「承認された回答」を複数選択できるといいのですが。
すべてをスクリプト化することを選択します。これには、すべてのストアドプロシージャとスキーマの変更が含まれます。 wysiwygツールも、派手な「同期」プログラムも必要ありません。
スキーマの変更は簡単です。スキーマとデータのすべての変更を含め、そのバージョンの単一ファイルを作成して維持するだけで済みます。これがバージョンxからx + 1への変換スクリプトになります。次に、それを本番バックアップに対して実行し、それを「毎日のビルド」に統合して、エラーなしで機能することを確認できます。後で書き込んだsqlを壊してしまう可能性があるため、すでに書き込んだsql/data sqlを変更または削除しないことが重要です。
-- change #1234
ALTER TABLE asdf ADD COLUMN MyNewID INT
GO
-- change #5678
ALTER TABLE asdf DROP COLUMN SomeOtherID
GO
ストアドプロシージャの場合、sprocごとに1つのファイルを選択し、ドロップ/作成フォームを使用します。すべてのストアドプロシージャは、展開時に再作成されます。欠点は、変更がソース管理外で行われた場合、変更が失われることです。同時に、それはどのコードにも当てはまりますが、DBAはこれに注意する必要があります。これにより、アップグレードによって変更が失われるため、チーム外のユーザーがストアドプロシージャをいじくり回すことがなくなります。
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をソース管理する方法の基本的な形式です。
補遺：Rickは正解です。DROP/ CREATEを使用してストアドプロシージャの権限を失うため、別のスクリプトを作成して特定の権限を再度有効にする必要がある場合があります。この許可スクリプトは最後に実行されます。私たちの経験では、ALTER句とDROP/CREATEセマンティクスの問題がさらに見つかりました。 YMMV
visual Studioで「データベースプロジェクト」を作成して、sQLコードを記述および管理し、プロジェクトを他のソリューションと一緒にバージョン管理下に置いてください。
私が最後の仕事で使用した解決策は、スクリプトがソース管理に追加されたときにスクリプトに番号を付けることでした。
01.CreateUserTable.sql
02.PopulateUserTable
03.AlterUserTable.sql
04.CreateOrderTable.sql
アイデアは、スクリプトを実行する順序を常に知っていて、スクリプト＃1を変更しようとした場合に発生する可能性があるデータ整合性の問題を管理する必要がないことです（これにより、＃2のINSERTが失敗する可能性があります）。
私はロバート・ポールソンの慣習に賛成（そして賛成）します。それは、あなたがそのような慣習を守る責任と規律を持つ開発チームの支配下にあることを前提としています。
私たちのチームにそれを「強制する」ために、私たちのソリューションはVisual Studio Team Edition for Database Professionalsから少なくとも1つのデータベースプロジェクトを維持します。ソリューションの他のプロジェクトと同様に、データベースプロジェクトはバージョン管理されます。これにより、データベース内のすべてを保守可能なチャンクに分割し、途中でチームを「統制」するのが自然な開発プロセスになります。
もちろん、Visual Studioプロジェクトであるため、完璧とは言えません。イライラしたり混乱したりする可能性のある多くの癖があります。タスクを実行する前に、プロジェクトがどのように機能するかを理解するにはかなりの時間が必要です。例には
- CSVファイルからのデータの展開 。
- ビルドタイプに基づくテストデータの選択的な展開 。
- Visual Studioは、特定のタイプのCLRアセンブリが埋め込まれたデータベースと比較するとクラッシュします 。
- 異なる認証スキームを実装するテストデータベースと本番データベースを区別する手段がない-SQLユーザーとActive Directoryユーザー。
しかし、データベースオブジェクトのバージョン管理を実践していないチームにとっては、これは良いスタートです。他の有名な代替案はもちろん Red GateのSQL Server製品スイート であり、これを使用するほとんどの人々はMicrosoftの製品よりも優れていると考えています。
SQL Serverのドロップ/作成スクリプトで留意する必要があるのは、オブジェクトレベルの権限が失われることです。代わりに、これらの権限を維持するALTERスクリプトを使用するように標準を変更しました。
オブジェクトを削除すると、sp_dependsによって使用される依存関係レコードが削除され、オブジェクトを作成するとそのオブジェクトの依存関係のみが作成されるという事実など、他にもいくつかの警告があります。したがって、ビューをドロップまたは作成すると、sp_dependsはそのビューを参照するオブジェクトを認識しなくなります。
物語の教訓、ALTERスクリプトを使用します。
ストアドプロシージャを含め、データベースを自動的にセットアップするスクリプトを作成する必要があると思います。次に、このスクリプトをソース管理に配置する必要があります。
私の経験からいくつかの異なる視点。 Oracleの世界では、すべてが「作成」DDLスクリプトによって管理されていました。 ahockleyが述べたように、オブジェクトごとに1つのスクリプト。オブジェクトを変更する必要がある場合は、そのDDLスクリプトが変更されます。すべてのオブジェクトスクリプトを呼び出すラッパースクリプトが1つあるため、現在のDBビルドを任意の環境にデプロイできます。これはメインコアの作成用です。
明らかにライブアプリケーションでは、たとえば新しい列を必要とする新しいビルドをプッシュするときはいつでも、テーブルを削除して新しく作成することはありません。 ALTERスクリプトを実行して、列を追加します。したがって、この種の変更を行う必要があるたびに、必ず2つのことを行います。1）変更DDLを書き込む、2）コア作成DDLを更新して変更を反映します。どちらもソース管理に入りますが、単一の変更スクリプトは、デルタを適用するためにのみ使用されるため、一時的な時点の変更です。
ERWinなどのツールを使用してモデルを更新し、DDLを順方向に生成することもできますが、私が知っているほとんどのDBAは、希望どおりにスクリプトを生成するためのモデリングツールを信頼していません。 ERWinを使用して、定期的にコアDDLスクリプトをモデルにリバースエンジニアリングすることもできますが、それを正しく表示することは非常に面倒です（実行するたびに）。
マイクロソフトの世界でも同様の戦術を採用しましたが、スクリプトとデルタの管理にRed Gate製品を使用しました。引き続きスクリプトをソース管理に配置します。オブジェクトごとにまだ1つのスクリプト（テーブル、sprocなど）。当初、DBAの中には、スクリプトを使用するよりもSQL Server GUIを使用してオブジェクトを管理することを好む人もいました。しかし、それが成長するにつれて、企業を一貫して管理することが非常に困難になりました。
DDLがソース管理にある場合、任意のビルドツール（通常はant）を使用してデプロイメントスクリプトを作成するのは簡単です。
私は、これを行うための最も簡単、最速、そして最も安全な方法は、弾丸を噛み、RedGateのSQLソースコントロールを使用することであることを発見しました。スクリプトを作成して数分でリポジトリに保存します。 RedGateがこの製品をロスリーダーと見なして、より広く使用できるようにしてほしいと思います。
過去の経験では、データベースの変更ソースは、製品のリリースごとに、データベースの変更が常にスクリプト化され、作業中のリリースに保存されるように制御されていました。構築プロセスを実行すると、各「アプリケーション」の現在のバージョンが格納されているデータベース内のテーブルに基づいて、データベースが自動的に現在のバージョンになります。次に、私たちが作成したカスタム.netユーティリティアプリケーションを実行してデータベースの現在のバージョンを確認し、スクリプトのプレフィックス番号の順に新しいスクリプトを実行します。次に、単体テストを実行して、すべてが正常であることを確認します。
スクリプトを次のようにソース管理に保存します（以下のフォルダー構造）。
テーブルとストアドプロシージャの現在の命名規則については少し錆びているので、自分の例では裸にしています...
[ルート]
[応用]
[バージョン]
[脚本]
\ scripts
私のアプリケーション\
1.2.1 \
001.MyTable.Create.sql
002.MyOtherTable.Create.sql
100.dbo.usp.MyTable.GetAllNewStuff.sql
アプリケーションとバージョンを考慮するバージョンテーブルを使用すると、アプリケーションは毎週の本番バックアップを復元し、現在のバージョン以降、データベースに対して必要なすべてのスクリプトを実行します。 .netを使用することで、これをトランザクションに簡単にパッケージ化でき、何かが失敗した場合はロールバックして電子メールを送信するため、リリースに不正なスクリプトがあることがわかりました。
したがって、すべての開発者はこれをソース管理で確実に維持し、データベースに対して実行する予定のすべてのスクリプトが確実に正常に実行されるように、協調リリースが行われるようにします。
これはおそらくあなたが探していたよりも多くの情報ですが、私たちにとっては非常にうまく機能し、すべての開発者を容易に参加させることができる構造を与えられました。
リリース日になると、運用チームはリリースノートに従い、ソース管理からスクリプトを取得し、夜間ビルドプロセス中に使用した.netアプリケーションを使用してデータベースに対してパッケージを実行します。何かが失敗すると、自動的にロールバックされ、データベースへの影響はありませんでした。
上記のロバートポールソンと同様に、私たちの組織はデータベースをソース管理下に置いています。ただし、違いは、スクリプトの数を制限しようとすることです。
新しいプロジェクトには、設定手順があります。バージョン1のスキーマ作成スクリプト、ストアドプロシージャ作成スクリプト、場合によっては初期データロード作成スクリプトがあります。すべてのプロシージャは、単一の確かに大規模なファイルに保存されます。 Enterprise Libraryを使用している場合は、ロギング用の作成スクリプトのコピーを含めます。 ASP.NETアプリケーションフレームワーク（認証、パーソナライゼーションなど）を使用するASP.NETプロジェクトの場合は、そのスクリプトも含めます。 （Microsoftのツールから生成し、さまざまなサイト間で複製できるように調整しました。楽しくはありませんが、貴重な時間を投資しました。）
魔法のCTRL + Fを使用して、必要なプロシージャを見つけます。 :)（SQL Management StudioにVSのようにコードナビゲーションがあったらいいですね。ため息！）
以降のバージョンでは、通常、upgradeSchema、upgradeProc、updateDateスクリプト、またはその両方が用意されています。スキーマの更新では、テーブルを可能な限り変更して、必要に応じて新しいテーブルを作成します。プロシージャの更新については、DROPとCREATEを行います。
この方法では、しわが1つポップアップします。データベースを生成するのは簡単であり、新しいデータベースを取得して現在のDBバージョンでスピードアップするのは簡単です。ただし、DB/schema/procの変更がそれらにアクセスするために使用されるコードと完全に同期されるように、DAL生成（現在-通常-SubSonicを使用）に注意する必要があります。ただし、ビルドパスにはSubSonic DALを生成するバッチファイルがあるので、SOPはDALコードをチェックアウトし、そのバッチファイルを再実行して、いつでもすべてチェックインします。スキーマやプロシージャの変更（これにより、ソースビルドがトリガーされ、共有依存関係が適切なDLLに更新されます...）
私の会社では、個々のコードファイルの場合と同じように、すべてのデータベースアイテムを個別のスクリプトとしてソース管理に格納する傾向があります。更新は最初にデータベースで行われ、次にソースコードリポジトリに移行されるため、変更の履歴が維持されます。
2番目のステップとして、すべてのデータベース変更が統合データベースに移行されます。この統合データベースは、運用データベースが配置後の状態を正確に表しています。また、現在の運用状態（または最後の展開）を表すQAデータベースもあります。統合データベースですべての変更が行われたら、スキーマ差分ツール（SQL ServerのRed GateのSQL Diff）を使用して、すべての変更をデータベース間で移行するスクリプトを生成します。
インストーラーと簡単に統合できる単一のスクリプトを生成するため、これはかなり効果的であることがわかりました。私たちがよく抱える最大の問題は、開発者が変更を統合に移行するのを忘れていることです。
ストアドプロシージャは、spごとに1つのファイルを取得します（存在する場合、標準のドロップ/作成ステートメントが上部にあります）。ビューと関数も独自のファイルを取得するため、バージョン管理と再利用が簡単になります。
スキーマは、最初はすべて1つのスクリプトで、バージョンの変更を行います。
これらはすべて、次のようなフォルダー構造でTFS（@ workまたはVisualSVN Server @ home for personal stuff）に接続されたビジュアルスタジオデータベースプロジェクトに保存されます。
- 事業
- 関数
-スキーマ
-ストアドプロシージャ
-ビュー
私は現在のプロジェクトで代替アプローチを使用しています-データベースをソース管理下に置いておらず、データベースの差分ツールを使用して、各リリースに到達したときに変更をスクリプト化しています。
これまでのところ、非常にうまく機能しています。
ストアドプロシージャをソース管理に保持します。
アプリケーションに関連するすべてのものをSCMに格納します。 DBスクリプトは通常、独自のプロジェクトに格納されますが、他のコードと同じように扱われます...設計、実装、テスト、コミット。
すべてをスクリプト化（オブジェクトの作成など）し、それらのスクリプトをソース管理に保存します。変更はどのように行われますか？これは、物事が行われる方法の標準的な実践の一部です。テーブルを追加する必要がありますか？ CREATE TABLEスクリプトを記述します。 sprocを更新しますか？ストアドプロシージャスクリプトを編集します。
オブジェクトごとに1つのスクリプトを使用します。
プロシージャの場合、スクリプトラッパーを使用してプロシージャをプレーンファイルに書き込み、それらのファイルからの変更を適用します。正しく適用されていれば、そのファイルをチェックインでき、そのファイルからも再現できます。
スキーマの変更については、スクリプトをチェックインして、加えた変更を段階的に行う必要がある場合があります。スクリプトを記述して適用し、チェックインします。次に、プロセスを構築して、各スキーマスクリプトを自動的に連続して適用することができます。
ストアドプロシージャをソース管理に保持します。私たち（または少なくとも私）が行う方法は、プロジェクトにフォルダーを追加し、各ファイルをSPに追加して、手動でコピーし、そこにコードを貼り付けます。それで、SPを変更するとき、ソース管理のファイルを手動で変更する必要があります。
人々がこれを自動的に行うことができるかどうか知りたいです。