ソース管理下のストアドプロシージャ、ベストプラクティス

現在、Tortoise SVNを使用して.NET Webアプリケーションのソース管理を行っています。SQL Serverストアドプロシージャをソース管理に組み込むための最良の方法は何ですか？現在、VS 2010を開発環境として使用しており、SQL Server Data Tools（SSDT）を使用して構外のSQL Server 2008 R2データベースに接続しています。

私が過去にやっていることは、プロシージャを.sqlファイルに保存し、このファイルをソース管理下に置くことです。これよりも効率的な方法があるはずだと思いますか？VS2010、SSDT、または実稼働マシンのSQL Serverにインストールできる拡張機能はありますか？

Redgateのようなツールはありますが、ソリューションのデータベースプロジェクト（SSDT？）にSQLファイルとして保存するのが最善であることが常にわかっています。

これに加えて、次のガイドラインを提案します。

• 常にSVNバージョンを「最新」/「最新」と見なします
• 実行するすべてのスクリプトがif exists then drop開始時に適切な「」を持っていることを確認してください
• もしあれば、許可をスクリプト化することを忘れないでください

最初にSSMSから直接スクリプトを作成してこれらのSQLファイルを作成できます。また、すべての「drop」と「create」、および権限をスクリプト化するようにSSMSを設定できます。

SQLファイルをソース管理に保存すると、SQLファイルのみを制御できます。実際のデータベースオブジェクトの変更を制御したり、複数のユーザーによる同じデータベースオブジェクトの同時変更を防止したりすることはできません（これも制御したいと思います）。使用するのは、サードパーティのツール（ApexSQLバージョン）、SSMSとVSの両方と統合されます。オブジェクトのデータベースバージョンを使用するか、ソース管理バージョンを使用するかを選択できます。データベースバージョンを編集している場合、自動的にチェックアウトされるのは自分だけなので、他のユーザーは編集できません（異なるユーザーからの変更をマージしません）。再度チェックインした場合にのみ、他のユーザーが変更できます。また、SCバージョンをライブオブジェクトのバージョンとは異なるものにすることができます（1日の出発時に編集を終了し、次の日にテストする予定です）

RedGateソース管理を使用して、ソース管理に接続します。

http://www.red-gate.com/products/sql-development/sql-source-control/

SSMSをソース管理リポジトリに直接フックし、静的データをチェックインすることもできます。

魔法のように働く

強く推奨された無料のAnkhsvnをお試しください。

ホームページから：

AnkhSVNは、マイクロソフトのVisual Studio 2005、2008、2010年のSubversionのソース管理プロバイダである、2012年。

AnkhSVNは、Visual StudioでサポートされるすべてのプロジェクトタイプにApache™Subversion®ソースコード管理サポートを提供し、Microsoft Visual Studio IDE内から最も一般的なバージョン管理操作を直接実行できるようにします。

保留中の変更ダッシュボードは、開発プロセスに関する独自の洞察を提供し、ソースコードと問題管理機能への簡単なアクセスを提供します。深いソースコード管理（SCC）の統合により、開発に集中できます。一方、AnkhSVNはすべての変更を追跡し、特定のニーズを効果的に処理するツールを提供します。

RedGateとVisual Studioのデータベースプロジェクトの両方を試しましたが、データベースプロジェクトにデータベース定義を保存することを好みます。データベースがソリューションの一部になるとすぐに、好みのソース管理プロバイダーを使用できます。ほとんどは優れたVisual Studio統合を備えています。

SSDTツールを使用すると、データベース定義の「最新バージョン」が得られるため、スキーマの比較を簡単に行い、スキーマアップグレードスクリプトを生成できます。

ただし、スキーマは通常、赤道の一部にすぎません。実際には、データベースにはすでに大量のデータがあることがわかります。そして、私のユーザーは、彼らがそれを失うとき、むしろ失望する傾向があります。

したがって、v1.0をリリースするとすぐに、アップグレードスクリプトを維持する必要が生じます。これらには単にスキーマの変更が含まれていることもありますが、多くの場合、他のテーブルのコンテンツに基づいてデフォルトを作成する必要があり、データをシードするまで特定の制約を解除する必要があります。私の好みは、これらのアップグレードスクリプトをデータベースプロジェクトの別のフォルダーに置くことです。これらは通常「v1.0からv1.1へのアップグレード」のように見えます。

データベースには常に現在のバージョン番号を示す参照テーブルがあるため、互換性のないアップグレードをブロックできます。アップグレードスクリプトの最初のステートメントは、現在のバージョンを確認し、予想と異なる場合は救済します。

データベースプロジェクトのもう1つの利点は、同じスキーマに基づいてさまざまなデータセットを展開できることです。開発用、QAチーム用、ユーザー受け入れテスト用、および自動統合テスト用の異なるデータセットがあります。データベースプロジェクトには展開後スクリプトを1つしか含めることができないため、ここでのコツは、「マスター」プロジェクトを参照する新しいデータベースプロジェクトを作成し、カスタムデータセットをそのプロジェクトの展開後プロセスの一部にすることです。

これらは私の2セントでした。あなたが出てくるプロセスが何であれ、何よりも、あなたとあなたのチームに合っていなければならず、できれば一般的なタスクのほとんどであなたをサポートしなければなりません。

私は自分でツールを書くことになりました。

無料でダウンロードできます-http://www.gitsql.net

同じ最終目標を達成したい他の人々に役立つことを願っています。

SQL Serverをソース管理する方法を説明する記事があります。http://gitsql.net/documentation-04_SQL_Server_and_GIT

私はそれをできるだけ簡単にしようとしました。（3画面）

• SQL Serverに接続する
• オブジェクトを選択
• / importにエクスポートするフォルダーを選択します

また、誤って-インポートまたはエクスポートする個々のオブジェクトを選択的に選択できる機能を追加しました。これにより、開発中に非常に簡単になります。

通常、ストアドプロシージャとテーブルを変更してから、これら2つのオブジェクトをGITディレクトリにエクスポートします。

次に、ソースツリーを使用して変更を視覚的に確認し、満足であればbitbucketにコミットします。

私の会社はこの新しいツール（無料）を開発しました。このツールは、SQLデータベースのスクリプトを簡単に抽出し、比較を行い、WinMergeを起動してスクリプトをライブデータベースと迅速に比較し、スクリプトの更新と変更の適用の両方の違いを同期させることができますデータベースに対して（より複雑でより多くのリスクを伴うテーブルを除く）。

Servanttは、SQL Serverデータベースをバージョン管理されたスクリプトと比較するためのWinMergeです。

ソフトウェア開発のベストプラクティスをサポートおよび奨励します。

• データベースオブジェクトをバージョン管理下に置く（*）
• 実稼働環境の開発者からアクセス権を削除する
• パフォーマンスのボトルネックと命名基準に関する手順/ビューの変更のDBAレビュー
• 完全修飾識別子とブラケット区切り文字を使用したオブジェクトの命名（CREATE PROCEDURE / VIEW / FUNCTION / etcスクリプトを修正）

（*）スクリプトは、Git、Subversion、TFS、Source Safe、またはその他のVCSの作業コピーであるローカルフォルダーに保存されます。

無料ダウンロード：http : //servantt.com

プロフェッショナル版（まだ開発中）は、まったく異なるものになります。IISの更新、Windowsサービスの更新などのタスクを自動化するための、展開の自動化（リリース管理）を対象としています。