データベースの変更を確認する（バージョン管理）

Question

私はデータベースのバージョン管理の重要性について多くの記事を読んでいます。しかし、データベースがあるべき状態にあるかどうかをチェックする方法を簡単に見つけることはできませんでした。

たとえば、「バージョン」という名前のテーブル（バージョン番号がそこに格納されています）を持つデータベースがあります。しかし、データベースは、バージョン番号を変更することなく、開発者がアクセスし編集することができます。たとえば、開発者がストアドプロシージャを更新し、バージョンデータベースの状態を更新しない場合は、バージョン値と同期していません。

これらの変更を追跡するにはどうすればよいですか？変更されたものを追跡する必要はありませんが、データベース表、ビュー、プロシージャなどがバージョン表に保存されているデータベースのバージョンと同期しているかどうかを確認するだけです。

なぜこれが必要ですか？デプロイメントを行うときに、データベースが「正しい」ことを確認する必要があります。また、すべての表または他のデータベース・オブジェクトをトラッキングする必要はありません。トリガーを使用せずにチェックすることは可能ですか？サードパーティのツールを使用しなくても可能ですか？データベースにチェックサムがありますか？

我々は編集2005年

SQL Serverを使用することとしましょう：

私は私が私たちの現在の環境について、もう少し情報を提供するべきだと思う - 私たちはベースを作成するために必要なすべてのスクリプトと「ベースライン」を持っていますバージョン（アプリケーションのデータオブジェクトと「メタデータ」が含まれます）。しかし、いくつかの追加のデータベースオブジェクト（追加のテーブル、ビュー、プロシージャなど）を備えたこの「ベース」バージョンのインストールが多数あります。 「ベース」バージョンで何らかの変更を加えた場合、一部のインストール（すべてではない）を更新する必要があります。その時点で、「ベース」が正しい状態であることを確認する必要があります。私は、すべてのデータベース・オブジェクトのスクリプトを作成/ドロップを生成するthis codeproject articleに基づいて、単純なVBScriptファイルを使用してい

おかげ

Answer 1

。私はこれらのスクリプトをバージョン管理下に置いた。

だから、データベースが最新であるか、まだバージョン管理に入れていなかった変化があるかどうかをチェックするために、私はこれを行う：

• バージョンからスクリプトを作成/ドロップの最新バージョンを取得
• バージョンコントロールからスクリプトを上書きして、チェックするデータベースのSqlExtractスクリプトを実行します。
• 私のサブバージョンクライアント（TortoiseSVN）には、バージョンと一致しないファイルがありますバージョン管理下で
• n owデータベースを更新するか、変更されたスクリプトをバージョン管理下に置く

Answer 2

私たちはDBGhostを使用して、データベースをバージョン管理します。現在のデータベースを作成するためのスクリプトはTFS（ソースコードとともに）に格納され、DBGhostはデルタスクリプトを生成して環境を現在のバージョンにアップグレードするために使用されます。 DBGhostは、静的/参照/コードデータのデルタスクリプトを作成することもできます。

伝統的な方法からのマインドシフトが必要ですが、十分にお勧めできない素晴らしい解決策です。サードパーティ製の製品ですが、自動化されたビルドおよび展開プロセスにシームレスに適合します。

Answer 3

最初の点：「規制」なしで物事を整理するのは難しいです。 また、予告なしに何かを変更した開発者は、深刻な問題を引き起こします。

とにかく「トリガーを使用しない」と言ってください。 具体的な理由は何ですか？

DDLトリガーをチェックアウトしていない場合。このようなトリガーは、何かが起きたかどうかを確認する最も簡単な方法です。

また、WHATが行っていたことを記録することもできます。

Answer 4

うまくいけば、誰かがこれよりもよりよい解決策を持っていますが、私はこのカップルの方法を使用してください：

• は、現在の開発版である「トランク」のデータベースを持っています。すべての作業は、リリースに含まれるように準備されているので、ここで行われます。
• リリースが行われるたびに：
  • 最後のリリースの「クリーン」データベースは、新しいものにコピーされるなど、にトランクからの変更をコピーするために使用される
  • SQL-Compare「DB_1.0.4_clean」 1.0.4_clean - これは含まれているものを正確にチェックすることもできます。
  • SQL Compareを使用して、以前のリリースと新しいリリース（DB_1.0.4_cleanからDB_1.0.3_cleanへの変更）の違いを検索し、変更スクリプト "1.0.3 to 1.0.4.sql"を作成します。

我々はまだこの部分を自動化するツールを構築しているが、目標は、データベースがでてきた、と変更スクリプトが適用された場合は、すべてのバージョンを追跡するためのテーブルがあることです。アップグレードツールは最新のエントリを検索し、各アップグレードスクリプトを1つずつ適用し、最終的にDBは最新バージョンになります。

私はこの問題はありませんが、他のチームメンバーによる変更から_cleanデータベースを保護するのは簡単です。さらに、変更スクリプトを生成するために事実の後にSQL Compareを使用するので、開発者が行くにつれてそれらを追跡する必要はありません。

• 私たちは実際にしばらくこのことをしましたが、大きな痛みでした。それは忘れ易いものでしたし、同時に変更が加えられていても必ずしも変更されていないため、個別に作成された変更スクリプトを使用して作成された完全アップグレードスクリプトでは、フィールドを追加してから、 1つのリリース。インデックスの変更などがある場合は、明らかにかなり痛いかもしれません。

SQLの比較についての素敵な点は、生成するスクリプトがトランザクション内にあり、失敗した場合はすべてを戻します。したがって、プロダクションDBが何らかの方法で変更されている場合、アップグレードは失敗し、デプロイメントチームはプロダクションDBで実際に_clean dbに対してSQL Compareを使用し、手動で変更を修正できます。私たちはこれを1回または2回（気にしない顧客）行うだけでした。

SQLの変更スクリプト（SQL Compareによって生成）は、バージョンコントロールシステム（Subversion）に格納されます。

Answer 5

すべてのデータベースへのアクセスを制限し、開発者がローカルデータベース（開発場所）と統合を行うことができる開発者サーバーにアクセスする必要があります。もっとも良いことは、ローカルの開発エリアにしかアクセスできず、自動化されたビルドで統合タスクを実行することです。 redgates sqlのようなツールをデータベースの差分を比較するのに使うことができます。いつ誰が何をしたのかという実行履歴を持ち、必要に応じてdb変更を元に戻すことができるように、すべての変更をソース管理（.sqlファイル）に保存することをお勧めします。

また、devsにローカルビルドスクリプトを実行させて、ローカルのdevboxを再起動させることができます。こうして彼らはいつもロールバックすることができます。さらに重要なのは、アプリの配管（リポジトリとデータアクセス）をテストし、ロジックがストアドプロシージャに自動で格納されることをテストする統合テストを作成できることです。初期化は実行され（dbのリセット）、統合テストが実行され（dbの綿毛の作成）、dbをクリーンな状態に戻すための再初期化など。

SVN /ナントスタイルのユーザーあなたのリポジトリに単一ブランチのコンセプトがあるなら、DotNetSlackers：http://dotnetslackers.com/articles/aspnet/Building-a-StackOverflow-inspired-Knowledge-Exchange-Build-automation-with-NAnt.aspxとhttp://dotnetslackers.com/articles/aspnet/Building-a-StackOverflow-inspired-Knowledge-Exchange-Continuous-integration-with-CruiseControl-NET.aspxでこのトピックに関する私の記事を読むことができます。

ビルドマスターのPERFORCEマルチブランチソートの場合、私はその種の自動化と構成管理について何か書き込むまで待たなければなりません。

UPDATE

@Sazug：「うん、私たちは完全な記事なしベーススクリプト+追加スクリプト:)自動化のその種のための任意の基本的なヒントを使用する場合、マルチブランチのいくつかの並べ替えを構築するでしょう？」あなたは を開発として蓄積ライブデータを持っている

• あなたは（のみアクティブDEV）新しい非生産型環境でのDBを制御
• 本番環境：最も一般的なデータベースの2つの形式があります。

  最初の設定ははるかに簡単で、devからprodまで完全に自動化でき、必要に応じてロールバックを含めることができます。このためには、データベースへのすべての変更を.sqlファイルで管理できるスクリプトフォルダが必要です。 tablename.sqlファイルを保存し、そのSQLアーティファクトへの更新が同じファイル内で実際に変更される.csファイルのようにバージョンを変更することはお勧めしません。 SQLオブジェクトはお互いに大きく依存しています。スクラッチからデータベースを構築すると、スクリプトに大きな変化が生じる可能性があります。このため、ファイル名の先頭にシーケンス番号を付けて、変更ごとに別々の新しいファイルを作成することをお勧めします。たとえば、000024-ModifiedAccountsTable.sqlのようなものです。その後、NAntContribからカスタムタスクまたは何かを使用するか、多数のSQL.exeコマンドラインツールの1つを直接実行して、000001-fileName.sqlから最後のファイルまでの空のデータベースに対してすべてのスクリプトを実行しますupdateScriptsフォルダに保存します。これらのスクリプトは、すべてあなたのバージョンコントロールにチェックインされます。そして、あなたはいつもクリーンなデータベースからスタートするので、新しいSQLが誰かにビルドを中断させると、いつでもロールバックすることができます。

  第2の環境では、生産に影響を与える可能性があるため、自動化は必ずしも最善のルートではありません。プロダクション環境との間で積極的に開発している場合は、実際にプロダクト環境にプッシュする前に自動化をテストできるように、マルチブランチ/環境が本当に必要です。上記の概念と同じ概念を使用できます。しかし、prod dbの最初から始めることはできず、ロールバックすることはより困難です。このような理由から、RedGate SQL Compareを使用することをお勧めします。 .sqlスクリプトは更新のためにチェックインされますが、更新を実行する前にステージングdbとprod dbの間の差分を自動化する必要があります。問題が発生した場合は、変更を同期させてロールバックを試みることができます。また、SQLの変更を自動プッシュする前に、バックアップの形式を取る必要があります。プロダクションで目を覚まさずに何かをするときは注意してください！すべての開発/品質/ステージング/パフォーマンス環境で本当の継続的な統合を行い、次に生産に進むときに手作業でいくつか手を加えれば、それは本当にそれほど悪くありません！

Answer 6

Visual Studio（特にデータベースエディション）をお持ちの場合は、作成してSQL Serverデータベースを指すことができるDatabase Projectがあります。プロジェクトはスキーマをロードし、基本的に他の多くの機能を提供します。これはコードプロジェクトのように動作します。また、Subversionの下に置くことができるように、テーブルとコンテンツ全体をスクリプト化する利点があります。 プロジェクトをビルドすると、データベースに整合性があることが検証されます。それはかなりスマートです。

Answer 7

私たちのプロジェクトの1つでは、データベース版のデータベースを保存していました。

データベース構造に対する各変更は、他のすべての変更の他にデータベースのバージョンをインクリメントした別のSQLファイルにスクリプト化されました。これはdb構造を変更した開発者によって行われました。

デプロイメントスクリプトは、現在のdbバージョンと最新の変更スクリプトに対してチェックされ、必要に応じてこれらのsqlスクリプトが適用されます。

Answer 8

"Three rules for database work"の最初と2番目のルールを破っているようです。開発者ごとに1つのデータベースを使用し、スキーマに1つの信頼できるソースを使用すると、すでに多くの助けになります。それでは、あなたのデータベースにBaselineがあり、さらに重要なことは、あなたがchange scriptsを使用していることを確信していません。最後に、Views, Stored Procedures and the LikeとBranching and Mergingの回答があります。

実際に、これらのリンクはすべて、Jeff Atwoodのこの偉大な記事：Get Your Database Under Version Controlに記載されています。 IMHOを読む必要があります。

Answer 9

第1に、本番データベースに開発者がアクセスできないようにするか、開発者（およびその他の人）は、変更管理システム外の本番システムに何も変更しないという厳しい指示に従うべきです。

変更制御は、作業が必要なシステムでは不可欠です（システム全体に関わるエンジニアが1人以上の場合）。

各開発者は、独自のテストシステムを持つ必要があります。彼らが変更を加えたいと思うのであれば、そうすることができますが、システムテストは生産と同じ変更が加えられたより制御されたシステムテストシステムで行う必要があります。もしこれをしなければ、リリースに頼ることはできません彼らは互換性のない環境でテストされているために働いています。

変更が行われる場合には、適切なスクリプトを作成し、彼らは現在のバージョンの上にきれいに適用することを確認するためにテストし、ロールバックは、あなたが右、ロールバックスクリプトを書いている*

*動作することをすべきか？

Answer 10

私は、開発者が本番データベースを変更するためのアクセス許可を持ってはならないということに同意します。開発者は共通の開発データベースを共有する必要があります（また、互いのつま先を踏まえてリスクを負う）か、独自のデータベースを用意する必要があります。前者の場合、SQL Compareのようなツールを使用して本番環境にデプロイすることができます。後者の場合は、開発ライフサイクル中に開発者データベースを定期的に同期させてから運用に移行する必要があります。

ここではRed Gateで、このプロセスをもっと簡単にするための新しいツール、SQL Source Controlをリリースする予定です。 SSMSに統合して、ボタンをクリックするだけでソースコントロールとの間でオブジェクトを追加および取得することができます。あなたはより多く見つけるか、私たちのアーリーアクセスプログラムへの申し込みに興味があれば、こちらのページをご覧ください。

http://www.red-gate.com/Products/SQL_Source_Control/index.htm

Answer 11

私はポストの残りの部分に同意する必要があります。データベースへのアクセス制限は生産上の問題を解決します。 DBGhostやDVCなどのバージョニングツールを使用すると、チームの他のチームがデータベースのバージョン管理を維持するのに役立ちます。