10

データベースのバージョン管理の重要性に関する多くの投稿を読みました。ただし、データベースが本来あるべき状態にあるかどうかを確認する簡単な解決策が見つかりませんでした。

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

それらの変更を追跡する方法は? 変更内容を追跡する必要はありませんが、データベース テーブル、ビュー、プロシージャなどがバージョン テーブルに保存されているデータベース バージョンと同期しているかどうかを確認するだけで済みます。

なぜこれが必要なのですか？展開を行うとき、データベースが「正しい」ことを確認する必要があります。また、すべてのテーブルまたはその他のデータベース オブジェクトを追跡する必要はありません。トリガーを使わずにチェックすることはできますか？サードパーティのツールなしで行うことは可能ですか? データベースにはチェックサムがありますか?

SQL Server 2005 を使用しているとしましょう。

編集:

現在の環境についてもう少し情報を提供する必要があると思います。基本バージョンを作成するために必要なすべてのスクリプトを含む「ベースライン」があります (アプリのデータ オブジェクトと「メタデータ」を含みます)。ただし、いくつかの追加のデータベース オブジェクト (追加のテーブル、ビュー、プロシージャなど) を含む、この「ベース」バージョンのインストールが多数あります。「ベース」バージョンに変更を加えた場合、一部のインストール (すべてではない) も更新する必要があります。その際、「ベース」が正しい状態であることを確認する必要があります。

ありがとう

4

11 に答える 11

6

「データベース業務の三原則」の第一、第二のルールを破っているようですね。開発者ごとに 1 つのデータベースを使用し、スキーマに単一の信頼できるソースを使用することは、すでに非常に役立ちます。次に、データベースのベースラインがあるかどうか、さらに重要なことに、変更スクリプトを使用しているかどうかがわかりません。最後に、 Views、Stored Procedures など、およびBranching and Mergingで他の回答を見つけることができます。

実際、これらのリンクはすべて、Jeff Atwood のすばらしい記事: Get Your Database Under Version Controlに記載されています。私見を読む必要があります。

于 2009-10-07T23:27:22.447 に答える
5

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

これは従来の方法からの考え方の転換を必要としますが、十分にお勧めできない素晴らしいソリューションです。これはサードパーティ製品ですが、自動化されたビルドおよび展開プロセスにシームレスに適合します。

于 2009-10-07T22:29:57.180 に答える
1

このコードプロジェクトの記事に基づいた単純な VBScript ファイルを使用して、すべてのデータベース オブジェクトのドロップ/作成スクリプトを生成しています。次に、これらのスクリプトをバージョン管理下に置きます。

したがって、データベースが最新かどうか、またはまだバージョン管理されていない変更があるかどうかを確認するには、次のようにします。

  • バージョン管理からドロップ/作成スクリプトの最新バージョンを取得します (この場合はサブバージョン)
  • チェックするデータベースの SqlExtract スクリプトを実行し、バージョン管理からスクリプトを上書きします
  • バージョン管理下のバージョンと一致しないファイルを Subversion クライアント (TortoiseSVN) で確認できるようになりました
  • データベースを更新するか、変更されたスクリプトをバージョン管理下に置く
于 2009-10-07T22:28:58.587 に答える
1

すべてのデータベースへのアクセスを制限し、開発者にローカル データベース (開発する場所) と、統合を行うことができる開発サーバーへのアクセスのみを許可する必要があります。最善の方法は、ローカルの開発エリアにのみアクセスし、自動ビルドで統合タスクを実行することです。redgates sql compare などのツールを使用して、データベースの差分を作成できます。すべての変更をソース管理下 (.sql ファイル) に保持することをお勧めします。これにより、誰がいつ何を行ったかの実行履歴を保持し、必要に応じてデータベースの変更を元に戻すことができます。

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

リポジトリに単一ブランチの概念を持つ SVN/nant スタイルのユーザー (または同様のユーザー) である場合は、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 マルチ ブランチ ビルド マスターである場合は、その種の自動化と構成管理について何かを書くまで待つ必要があります。

アップデート

@Sazug: 「ええ、ベース スクリプトと追加スクリプトを使用する場合は、ある種のマルチ ブランチ ビルドを使用します :) 記事全体がなくても、その種の自動化に関する基本的なヒントはありますか?」最も一般的なデータベースには、次の 2 つの形式があります。

  • 新しい非本番タイプの環境でデータベースを制御します（アクティブな開発のみ）
  • 開発中にライブデータが蓄積される本番環境

最初のセットアップははるかに簡単で、開発から本番まで完全に自動化でき、必要に応じて本番のロールバックを含めることができます。これには、データベースへのすべての変更を .sql ファイルで維持できるスクリプト フォルダーが必要です。tablename.sql ファイルを保持してから、.cs ファイルのようにバージョン管理することはお勧めしません。その sql アーティファクトへの更新は、時間の経過とともに同じファイルで実際に変更されます。SQL オブジェクトが相互に大きく依存していることを考えると、データベースをゼロから構築すると、スクリプトに重大な変更が発生する場合があります。このため、ファイル名の先頭にシーケンス番号を付けて、変更ごとに個別の新しいファイルを保持することをお勧めします。たとえば、000024-ModifiedAccountsTable.sql のようなものです。次に、カスタム タスクまたは NAntContrib から何かを使用するか、多くの ??SQL.exe コマンド ライン ツールのいずれかを直接実行して、000001-fileName.sql から最後のファイルまで、空のデータベースに対してすべてのスクリプトを実行できます。 updateScripts フォルダーにあります。これらのスクリプトはすべて、バージョン管理にチェックインされます。また、常にクリーンなデータベースから開始するため、誰かの新しい SQL によってビルドが中断された場合は、いつでもロールバックできます。

2 番目の環境では、本番環境に影響を与える可能性があるため、自動化が常に最善の方法であるとは限りません。本番環境に対して/本番環境向けに積極的に開発している場合は、実際に本番環境にプッシュする前に自動化の方法をテストできるように、マルチブランチ/環境が本当に必要です。上記と同じ概念を使用できます。ただし、prod db では実際にゼロから始めることはできず、ロールバックはより困難です。このため、ビルド プロセスで同様の RedGate SQL Compare を使用することをお勧めします。.sql スクリプトは更新目的でチェックインされますが、更新を実行する前に、ステージング データベースと本番データベースの間の差分を自動化する必要があります。問題が発生した場合は、変更の同期と製品のロールバックを試みることができます。また、SQL の変更を自動プッシュする前に、なんらかの形式のバックアップを取る必要があります。本番環境で人の目を気にせずに何かをするときは注意してください! dev/qual/staging/performance のすべての環境で真の継続的インテグレーションを行ってから、本番環境にプッシュする際にいくつかの手動の手順を実行する場合...それはそれほど悪くはありません!

于 2009-10-07T22:38:16.760 に答える
0

開発者が本番データベースを変更する権限を持ってはならないという他の投稿に同意します。開発者は、共通の開発データベースを共有する必要があります（そして、お互いの足を踏み入れるリスクがあります）か、独自の個別のデータベースを持っている必要があります。前者の場合、SQLCompareなどのツールを使用して本番環境にデプロイできます。後者の場合、本番環境にプロモートする前に、開発ライフサイクル中に開発者データベースを定期的に同期する必要があります。

ここRedGateでは、このプロセスをはるかに簡単にするように設計された新しいツール、SQLSourceControlをまもなくリリースする予定です。SSMSに統合し、ボタンをクリックするだけでソース管理との間でオブジェクトを追加および取得できるようにします。早期アクセスプログラムの詳細やサインアップに興味がある場合は、次のページにアクセスしてください。

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

于 2009-10-28T23:11:31.893 に答える
0

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

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

デプロイメントスクリプトは、現在のデータベースバージョンおよび最新の変更スクリプトと照合し、必要に応じてこれらのSQLスクリプトを適用しました。

于 2009-10-07T23:22:48.027 に答える
0

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

于 2009-10-07T23:08:31.430 に答える
0

まず、開発者が本番データベースにアクセスできないようにするか、変更管理システムの外部で本番システムにいかなる種類の変更も加えないように、開発者 (および他の全員) に厳密な指示を与える必要があります。

変更管理は、機能することが期待されるすべてのシステムで不可欠です (システム全体に 1 人以上のエンジニアが関与する場合)。

各開発者は独自のテスト システムを持つ必要があります。それを変更したい場合は変更できますが、システムテストは、本番環境と同じ変更が適用された、より制御されたシステムテストシステムで行う必要があります。これを行わないと、リリースに依存できません。互換性のない環境でテストされているため、機能しています。

変更が加えられたら、適切なスクリプトを作成してテストし、それらが現在のバージョンに完全に適用され、ロールバックが機能することを確認する必要があります*

*あなたはロールバック スクリプトを書いていますよね?

于 2009-10-08T06:32:58.680 に答える
0

投稿の残りの部分に同意する必要があります。データベースへのアクセス制限は、本番環境の問題を解決します。次に、DBGhost やDVCなどのバージョン管理ツールを使用すると、あなたとチームの他のメンバーがデータベースのバージョン管理を維持するのに役立ちます

于 2010-06-03T23:47:50.837 に答える
0

1点目：「規則」がないと物事を整理するのは難しい。またはあなたの例では、開発者が通知なしに何かを変更すると、深刻な問題が発生します。

とにかく - あなたは「トリガーを使わずに」と言います。これには具体的な理由はありますか？

そうでない場合は、DDL トリガーを確認してください。このようなトリガーは、何かが起こったかどうかを確認する最も簡単な方法です。

また、何が起こっているのかをログに記録することもできます。

于 2009-10-07T22:30:00.090 に答える
0

誰かがこれよりも優れた解決策を持っていることを願っていますが、私はいくつかの方法を使用してこれを行います。

  • 現在の開発バージョンである「トランク」データベースを用意します。リリースに含める準備が整っているため、すべての作業はここで行われます。
  • リリースが行われるたびに:
    • 最後のリリースの「クリーンな」データベースが新しいデータベースにコピーされます (例: 「DB_1.0.4_clean」)。
    • SQL-Compareを使用して、トランクから 1.0.4_clean に変更をコピーします。これにより、何が含まれるかを正確に確認することもできます。
    • 以前のリリースと新しいリリースの違い (DB_1.0.4_clean から DB_1.0.3_clean への変更) を見つけるために SQL Compare が再度使用され、変更スクリプト "1.0.3 to 1.0.4.sql" が作成されます。

この部分を自動化するためのツールはまだ作成中ですが、目標は、データベースのすべてのバージョンと、変更スクリプトが適用されたかどうかを追跡するテーブルを作成することです。アップグレード ツールは最新のエントリを探し、各アップグレード スクリプトを 1 つずつ適用し、最終的に DB を最新バージョンにします。

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

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

SQL 比較の優れた点は、生成されるスクリプトがトランザクション内にあることです。失敗すると、すべてがロールバックされます。そのため、本番 DB が何らかの方法で変更されている場合、アップグレードは失敗します。その後、展開チームは実際に本番 DB で _clean データベースに対して SQL Compare を使用し、変更を手動で修正できます。これを行う必要があったのは 1 回か 2 回だけです (くそー顧客)。

.SQL 変更スクリプト (SQL Compare によって生成される) は、バージョン管理システム (subversion) に保存されます。

于 2009-10-07T22:34:08.557 に答える