sql-server - ソース管理でデータベースの変更をどのように追跡しますか?

Question

ほとんどのプロジェクトで SQL Server 2000/2005 と Vault または SVN を使用しています。どちらのソース管理システムでも、データベーススキーマ/プロセスの変更をキャプチャする適切なソリューションが見つかりませんでした。

私たちの現在のソリューションは非常に面倒で、実行するのが困難です (変更したオブジェクトをスクリプト化してデータベースにコミットします)。

カスタム開発でこの問題に対処する方法については多くのアイデアがありますが、既存のツールをインストールしたいと思います (有料ツールは問題ありません)。

では、データベースコードの変更をどのように追跡するのでしょうか。おすすめのツールはありますか？

編集：

すべての提案をありがとう。時間の制約があるため、ここでは自分でロールバックしたくありません。そして、ほとんどの提案には、開発者が何らかの手順に従う必要があるという欠陥があります。

代わりに、理想的なソリューションは、SQL データベースの変更を監視し、検出された変更を SCM にコミットすることです。たとえば、SQL Server に、変更を加えたユーザーの DML 変更を記録し、そのオブジェクトのスクリプトを SCM にコミットできるアドオンがあれば、私はワクワクします。

社内では次の 2 つのシステムについて話し合っています。次に、チェックインプロシージャはそれを SCM にスクリプト化します。2. スケジュールされたジョブを実行して変更を検出し、(匿名で) SCM にコミットします。

ユーザーアクションの部分をスキップして、システムがこれらすべてを自動的に処理できるようにするとよいでしょう。

score 15 · Accepted Answer

Visual Studio データベースエディションを使用して、データベースのスクリプトを作成します。魔法のように機能し、任意のソース管理システムを使用できます。もちろん、VS プラグインがあれば最高です。このツールには他にも多くの便利な機能があります。この素晴らしいブログ記事でそれらをチェックしてください

http://www.vitalygorn.com/blog/post/2008/01/Handling-Database-easy-with-Visual-Studio-2008.aspx

または、MSDN で公式ドキュメントを確認してください。

score 6 · Accepted Answer

さまざまなサードパーティツールを使用して、SSMS からデータベースの変更を直接追跡できます。ApexSQL Source Controlは、バージョニングに含まれるすべてのデータベースオブジェクトを自動的にスクリプト化します。コミットは、ツールによって自動的に実行できません。代わりに、ユーザーはコミットする変更を選択する必要があります。

リポジトリから変更を取得するとき、ApexSQL Source Control は SQL データベースの参照整合性を認識します。したがって、トランザクションにラップされるすべての依存オブジェクトを含む同期スクリプトが作成されるため、エラーが発生しない場合はすべての変更が適用されるか、選択された変更が適用されません。いずれにせよ、データベースの整合性は影響を受けません。

score 5 · Accepted Answer

ビジュアルスタジオのデータベースプロジェクトも、ソース管理のジレンマに対する適切な解決策であると言わざるを得ません。正しく設定されていれば、IDE からデータベースに対してスクリプトを実行できます。スクリプトが古い場合は、最新のものを取得し、DB に対して実行します。必要に応じて、すべてのオブジェクトを再作成するスクリプトを用意します。新しいオブジェクトは、このスクリプトにも手動で追加する必要がありますが、1 回だけです。

私はすべてのテーブル、proc、および関数を独自のファイルに入れるのが好きです。

score 3 · Accepted Answer

貧しい人の解決策の 1 つは、最新の db スキーマをファイルにダンプする pre-commit フックスクリプトを追加し、そのファイルをコードと共に SVN リポジトリにコミットすることです。次に、任意のリビジョンから db スキーマファイルを比較できます。

score 1 · Accepted Answer

私たちの環境では、DBを手動で変更することはありません。すべての変更はリリース時にスクリプトによって行われ、スクリプトはバージョン管理システムに保持されます。この手順の重要な部分の1つは、データを失うことなく、すべてのスクリプトを同じDBに対して再度実行できるようにすることです。たとえば、列を追加する場合、列がすでに存在する場合は何もしないようにしてください。

「提案には、開発者が何らかの手順に従う必要があるという欠陥があります」についてのあなたのコメントは、実に物語です。それは欠陥ではなく、機能です。バージョン管理は、開発者が手順に従うのに役立ち、手順の負担を軽減します。手順に従わない場合は、バージョン管理は必要ありません。

score 1 · Accepted Answer

ゼロから独自のものを作成することはあまり実行可能ではありませんが、Redgate SQL Compare SDKのような SQL 比較ツールを使用して変更ファイルを生成すると、必要なものをハーフロールしてからそれらのファイルをチェックするだけで、それほど時間はかかりません。ソース管理に。開発システムから稼働中のシステムへの変更をわずか数時間で更新するために、私自身も似たようなものをロールバックしました。

score 1 · Accepted Answer

完全な SQL-CreateDB-statement に加えて、SQL-alter-Statement をコミットするだけです。

score 1 · Accepted Answer

SQL2000 では、各オブジェクトを独自のファイルに生成し、それらをすべてソース管理にチェックインします。ソース管理に変更履歴を処理させます。

SQL 2005 では、すべてのオブジェクトを個別のファイルに生成するコードを少し記述する必要があります。

score 0 · Accepted Answer

あるプロジェクトでは、データベース内のすべての重要なデータを外部の場所から自動的に再作成できるように、設計に細心の注意を払って配置しました。起動時に、データベースが存在しない場合はアプリケーションによって作成され、アプリケーションソースコードのスキーマを使用して外部データソースからデータが入力されます (したがって、アプリケーションでバージョン管理されます)。データベースストア名 (ほとんどのデータベースマネージャーは複数のデータベースを許可しますが、sqlite ファイル名) にはスキーマバージョンが含まれており、スキーマの変更をコミットするたびにスキーマバージョンを増やします。これは、アプリケーションを別のスキーマで新しいバージョンに再起動すると、新しいデータベースストアが自動的に作成されて入力されることを意味します。デプロイを古いスキーマに戻す必要がある場合、古いバージョンの新しい実行では古いデータベースストアが使用されます。

基本的に、データベースは従来のアプリケーションヒープのように機能し、永続性、トランザクションの安全性、静的型付け (Python を使用しているため便利)、および一意性制約の利点があります。ただし、データベースを削除して最初からやり直すことについてはまったく心配していません。また、プロセス状態のハックが元に戻るのと同じように、データベースを手動でハックしようとすると、次の展開で元に戻ることを人々は知っています。次回の再起動時。

データベースファイル名を切り替えてアプリケーションを再起動するだけで、自動的に再構築されるため、移行スクリプトは必要ありません。クライアントごとに 1 つのデータベースを使用するようにアプリケーションインスタンスをシャーディングすると便利です。また、データベースのバックアップの必要性も減少します。

外部ソースからのデータベースの構築に、アプリケーションをダウンさせたままにするよりも時間がかかる場合、このアプローチは機能しません。

score 0 · Accepted Answer

私たちのデータベース管理者は定期的に SVN にあるものに対して prod をチェックし、ソース管理下にないオブジェクトを削除します。開発者がソース管理に何かを入れることを決して忘れないようになるまでに、一度だけかかります。

また、スクリプトなしでオブジェクトを本番環境に移動することも許可していません。これは、開発者が簡単に実施できる本番環境の権限を持っていないためです。

score 0 · Accepted Answer

.Net を使用していて、Migrator.Net で Rails のアプローチが気に入っている場合は、Migrator.Netをお勧めします。

Visual Studio でセットアップする手順を説明した素敵なチュートリアルを見つけました。また、参照用のサンプルプロジェクトも提供しています。

score 0 · Accepted Answer

データベースを更新するカスタムツールを開発しました。データベーススキーマは、データベースに依存しない XML ファイルに格納され、ツールによって読み取られて処理されます。スキーマは SVN に保存され、何が変更されたかを示す適切なコメントが追加されます。それは私たちにとって非常にうまく機能します。

この種のソリューションは、ほとんどのプロジェクトにとって間違いなくやり過ぎですが、時には作業が楽になることもあります。

score 0 · Accepted Answer

挿入更新や削除などのすべての変更を追跡するには、SVN に多くのオーバーヘッドが発生します。スキーマを変更する (alter、drop、create) などの ddl の変更のみを追跡することをお勧めします。テーブルと、そのテーブルにデータを挿入するためのトリガーを作成することで、このスキーマ追跡を簡単に行うことができます。必要なときはいつでも、そのテーブルからクエリを実行して変更ステータスを取得できますhereとhereに多くの例があります

sql-server - ソース管理でデータベースの変更をどのように追跡しますか?

13 に答える 13

Related

Reference