6

データベース変更管理ワークフローを導入しました。これはSQLスクリプトに基づいています（したがって、マネージコードベースのソリューションではありません）。

基本的な設定は次のようになります。 

Initial/
    Generate Initial Schema.sql
    Generate Initial Required Data.sql
    Generate Initial Test Data.sql
Migration
     0001_MigrationScriptForChangeOne.sql
     0002_MigrationScriptForChangeTwo.sql
     ...

データベースを起動するプロセスは、すべての初期スクリプトを実行してから、順次移行スクリプトを実行することです。ツールは、バージョン管理要件などを考慮します。

私の質問は、この種の設定では、これを維持することも有用ですか？

Current/
    Stored Procedures/
        dbo.MyStoredProcedureCreateScript.sql
        ...
    Tables/
        dbo.MyTableCreateScript.sql
        ...
    ...

「これ」とは、データベースの現在/最新バージョンを起動するための作成スクリプトを表すスクリプトのディレクトリ（オブジェクトタイプで区切られた）を意味します。

どういうわけか、私はそのアイデアが本当に好きですが、その必要性を具体的に正当化することはできません。私は何かが足りないのですか？

利点は次のとおりです。

  • 開発とソース管理の場合、これまでと同じファイルごとのオブジェクトの設定が必要になります
  • 展開の場合、Initial + Migrationを実行するか、Current /からスクリプトを実行することにより、新しいDBインスタンスを最新バージョンにスピンアップできます。
  • 開発者の場合、開発を行うためにDBインスタンスを実行する必要はありません。Current/フォルダで「オフライン」開発を行うことができます。

欠点は次のとおりです。

  • 変更するたびに、Current /フォルダー内のスクリプトを更新し、（Migration /フォルダー内に）移行スクリプトを作成する必要があります。

ご入力いただきありがとうございます！

4

3 に答える 3

6

実際、これが最善の方法です。面倒に聞こえるかもしれませんが、ツールやVSDB.schemaファイルの展開などのSQLCompareを使用する他の方法よりも優れています。私はしばらくの間、正確にsmaeアプローチについて議論してきました：バージョン管理とあなたのデータベース。私のアプリは、最初のスクリプトからv1スキーマをデプロイしてから、バージョンごとにアップグレードスクリプトを実行します。各スクリプトは、バージョンN-1からNにアップグレードする方法を知っていますが、それだけです。最終結果は現在のバージョンです。

最大の欠点は、信頼できる.sqlファイルがないことです。オブジェクト（プロシージャ、テーブル、ビューなど）の現在のバージョンを見つけることもできません。ただし、以前のバージョンよりもアプリをデプロイできることの利点と、適切に制御およびテストされたスクリプトによってデプロイできることの利点は、欠点をはるかに上回ります。

この展開プロセス（v1を展開するスクリプト。次にv1.1を適用し、次にv1.2 ...最後にv4.5を適用するまで、現在）を使用することに不満がある場合は、次の点に注意してください。まったく同じプロセスが使用されます。リリース間でデータベースをアップグレードするためにSQLServerによって内部的に。古いデータベースを接続すると、有名な「データベースがバージョン611から612へのアップグレードを実行している」ことがわかり、アップグレードが段階的に行われ、現在のバージョン651（または現在のバージョン）に直接アップグレードされないことがわかります。 ）。また、アップグレードでは、v。611よりもv 651を展開するための差分ツールも実行されません。これは、使用するアプローチが最善であるため、一度に1ステップずつアップグレードします。

そして、あなたの質問に実際の答えを追加するために、かなり斜めの暴言を投稿した後（私が強い意見を持っているトピックですか、教えていただけますか？）：現在のバージョンのスクリプトバージョンを持つことは価値があると思いますが、私はそれを思います連続した統合ビルドプロセスの成果物である必要があります。つまり、ビルドサーバーは（アップグレードスクリプトを使用して）現在のデータベースをビルドしてから、ビルドステップとしてデータベースをスクリプト化し、現在のバージョンのスキーマスクリプトを使用してビルドドロップを生成する必要があります。ただし、これらは検索とコード検査のリファレンスとしてのみ使用する必要があり、デプロイメントの成果物である私の2Cとしては使用しないでください。

于 2010-03-23T22:20:29.900 に答える
1

長期的には、事態はさらに複雑になると思います。あるコンテキストでそのスクリプトをテストし、本番環境などの別のコンテキストで正しく機能することを確認できるように、バージョン全体を1つのスクリプトに含める必要があります。

于 2010-03-23T21:21:29.827 に答える
0

マーティン、

現実の世界にいる場合、本番データベースは更新のみを受け入れます。最初から「作成」することはありません。したがって、保存、監視、レビューなどで最も重要なことは、一連の更新スクリプトです。これらは本番環境に移行するためのスクリプトであるため、本当に重要なのはこれらだけです。

あなたはそれらをプライマリにすることによって正しいことをしています。ただし、開発者は、スキーマがどのように見えるかについての「現在の状況」を把握できる必要があります。DBAもこれを行うのが好きですが、（あまりにも）頻繁に本番サーバーにログインして、ある種のGUIツールを起動することによってこれを行います。（うわぁ！）

あなたのアプローチについて私が持っている唯一の予約は、オブジェクトタイプ別の現在/以前のスキーマです。これらのスクリプトは、データベース自体のダンプから自動的に生成される必要があります。タイプごとに自動的に分類できるのであれば、すばらしいです。そうでない場合は、ナビゲートしやすくするためにできることを実行しますが、ガイドルールは常に「ライブデータベースから自動的に生成される」必要があります。

于 2010-03-24T21:17:32.107 に答える