SQL Serverによるバージョン管理

新しいプロジェクトを開始し、バージョン管理システムとしてSVN（Tortoiseを使用）を使用しています。同じシステムを使用してSQL Serverデータベースも維持できるかどうか疑問に思っていました。

テーブル/関数/ビュー/プロシージャ/トリガー/などをバージョン管理したいと思います。とにかくテストデータになるため、私のデータはそうではありません。これをどのように設定するのかよくわかりません。いくつかのオプションに出くわしましたが、足りないものがあったかどうか、そしてそれを実行するために役立つガイドや何かがあるかどうかを知りたいです。

Red Gateを見たことがありますが、無料のもの（または少なくとも非常に低価格）を探しています。私はいつでも自分で何かを書くことができることを知っていますが、私はそのことに時間を費やそうとはしていません。

私が遭遇したことの1つは、ScriptDB4Svnと呼ばれるオープンソースパッケージをまとめたことです。誰もこれを以前に使用しましたか？いいですか？必要なことはできますか？セットアップは簡単ですか？

技術的にはツールさえ必要ありません。オブジェクトを直接スクリプト化し、ソース管理にチェックインできます。ツールなしではもう少し作業になりますが、間違いなく実行可能です。

ところで：私はRedGateツールを使用しましたが、それはかなり滑らかでお金の価値があります。

ほとんどがMicrosoftのセットアップになっているようです。データベースプロジェクト（以前はDataDudeとして知られていました）を見ることができます。基本的に、Visual StudioでT-SQLを一流の言語に変えます。あなたはできる：

• プロジェクトのコンパイル-最終的なスクリプトを作成するだけでなく、オブジェクト名などが存在することを確認します。
• 静的コード分析を実行します。たとえば、[dbo]30％のパフォーマンス向上のために、スキーマ（ほとんどの場合）を含めることにより、常にオブジェクトを参照するようにします。
• プロジェクトの異なるバージョンを比較させることにより、diffスクリプトを作成します。
• データベースまたはスクリプトからプロジェクトを更新します（リバースエンジニア）。
• インテリセンス。
• 作図ツールはありません。

また、ソース管理下でコードとデータベースコードをうまく統合します。あなたがいる場合男アップいいです- （代わりに、SSMSでダヴィンチのツールを使用しての）、スクリプト、データベースのオブジェクトは、あなたはまた、1つのIDEを使って着陸します。

Railsを使用できます。Railsには、データベース移行の概念があり、これを適用またはロールバックできます。私の経験では、これはデータベースをバージョン管理する最良の方法です。これらの移行ファイルをSVNにチェックインします。

私の現在のプロジェクトでは、Rubyでアプリケーションを開発していませんが、データベースの管理にまだRailsを使用しています。私は他の方法でそれをしません。

これは、stackoverflowで以前に説明されています：https : //stackoverflow.com/questions/2750278/sql-server-2008-create-database-script-schema-data-with-command-line

また、この外部の記事には、Windowsアプリケーションの形式のサンプルコードと共に、http：//www.sqlteam.com/article/scripting-database-objects-using-smo-updatedの追加情報が記載されています。

あなたがしたいことは私がMS Accessのために自分でやったことなので、それがあなたにいくつかのアイデアを与える場合に私がやったことを教えます：ADOのスキーマとデータを変換するAdo2Xmlと呼ばれるモジュールを書きました-xmlへのアクセス可能なデータベース、およびその逆。ただし、テーブルとビューについてのみ知っています。ストアドプロシージャ、トリガー、何もありません。とにかく、あなたの場合、このモジュールは、おそらくあなたがMS-SQLで何をしたいのかを見つけるツールに置き換えられます。そのため、アプリケーションを起動するたびに、データベースのタイムスタンプと保存されたxmlファイルのタイムスタンプが比較されます。xmlファイルがより新しい場合、データベースを破棄し、Ado2Xmlを呼び出してxmlファイルから再作成します。アプリケーションが終了すると、逆になります。Ado2Xmlを呼び出して、データベースをxmlファイルにエクスポートします。実際、データベーススキーマを抽出するADOオブジェクトは何らかの理由で非常に遅いため、エクスポートプロセスに時間がかかります。したがって、アプリケーションが終了する直前にアプリケーションが終了し、Visual Studioがデバッグレイアウトから編集レイアウトに切り替わるのを待つ必要を回避するために、アプリケーションが終了する直前に外部アプリを起動してエクスポートを実行し、終了できるようにしますすぐに。

はい、以前のプロジェクトで同様のツール（社内で開発）を使用しました。すべてのテーブル、ビュー、sproc、トリガーなどを個々の.sqlファイルにスクリプト化します。次に、「開発」データベースのすべてがソース管理に反映されていることを「検証」するスクリプトを毎晩実行しました。

したがって、通常のワークフローでは、コードを変更し、必要に応じて開発データベースの対応するテーブルとsprocを変更してから、スクリプト化されたすべての.sqlファイルを更新するツールを実行します。その後、すべてを一度にチェックインします。

問題は、ツールを実行するのを忘れた場合、データベースが「正しい」ためにコードが「機能する」（および単体テストに合格する）が、新しいsprocs / tablesはソース管理ではないことでした。

そのため、毎晩、ソースコードのチェックアウトを行ったスクリプトがあり、すべてのスクリプトを更新するためのツールを使用しています。違いがあった場合、誰かが変更をチェックインするのを忘れて、電子メール通知が生成されたことを意味します。基本的には、ソース管理を最新の状態に保つことを忘れないようにするための単なる方法でした。

数日にわたる変更に取り組むのが難しくなったため、少し面倒でしたが、何もないよりはましでした...