SQL Serverデータベースのバージョン管理

08-06-2019
|

質問

データベースをバージョン管理下に置きたいと考えています。始めるためのアドバイスや推奨記事がある人はいますか?

少なくとも常に持ちたいと思っています いくつかの そこにあるデータ（としてミョウバン言及:ユーザータイプと管理者)。また、パフォーマンス測定のために生成されたテストデータの大規模なコレクションが必要になることもよくあります。

解決

マーティン・ファウラーは、このテーマに関して私のお気に入りの記事を書きました。 http://martinfowler.com/articles/evodb.html. 。私は、スキーマダンプをバージョン管理下に置かないことにしました。 ミョウバン 実稼働データベースを簡単にアップグレードする方法が必要なため、他の人が提案します。

単一の実稼働データベースインスタンスを持つ Web アプリケーションの場合、私は 2 つの手法を使用します。

データベースアップグレードスクリプト

スキーマをバージョン N から N+1 に移行するために必要な DDL を含むシーケンスデータベースアップグレードスクリプト。(これらはバージョン管理システムに組み込まれます。) _version_history_ テーブル、次のようなもの

create table VersionHistory (
    Version int primary key,
    UpgradeStart datetime not null,
    UpgradeEnd datetime
    );

アップグレードスクリプトが実行されるたびに、新しいバージョンに対応する新しいエントリを取得します。

これにより、どのバージョンのデータベーススキーマが存在するのかが簡単に確認でき、データベースアップグレードスクリプトが 1 回だけ実行されることが保証されます。繰り返しますが、これらはないデータベースダンプ。むしろ、各スクリプトは、変化あるバージョンから次のバージョンに移行するために必要です。これらは、実稼働データベースを「アップグレード」するために適用するスクリプトです。

開発者サンドボックスの同期

実稼働データベースをバックアップ、サニタイズ、および縮小するためのスクリプト。実稼働 DB にアップグレードするたびにこれを実行します。
開発者のワークステーション上でバックアップを復元 (および必要に応じて微調整) するスクリプト。各開発者は、運用 DB にアップグレードするたびにこのスクリプトを実行します。

注意:私の自動テストはスキーマは正しいが空のデータベースに対して実行されるため、このアドバイスはあなたのニーズに完全には適合しません。

他のヒント

Red Gate の SQL Compare 製品を使用すると、オブジェクトレベルの比較を実行し、そこから変更スクリプトを生成できるだけでなく、[オブジェクト名].sql を 1 回作成するだけで、データベースオブジェクトをオブジェクトタイプごとに編成されたフォルダー階層にエクスポートすることもできます。これらのディレクトリ内のオブジェクトごとにスクリプトを作成します。オブジェクトタイプの階層は次のようになります。

\機能
\安全
\セキュリティ\役割
\セキュリティ\スキーマ
\セキュリティ\ユーザー
\ストアドプロシージャ
\テーブル

変更を加えた後にスクリプトを同じルートディレクトリにダンプすると、これを使用して SVN リポジトリを更新し、各オブジェクトの実行履歴を個別に保存できます。

これは開発を取り巻く「困難な問題」の 1 つです。私の知る限り、完璧な解決策はありません。

データではなくデータベース構造のみを保存する必要がある場合は、データベースを SQL クエリとしてエクスポートできます。(Enterprise Manager の場合:データベースを右クリック→SQLスクリプトの生成。オプションタブで「オブジェクトごとに 1 つのファイルを作成」を設定することをお勧めします)。その後、これらのテキストファイルを svn にコミットし、svn の差分機能とログ機能を利用できます。

これを、いくつかのパラメータを取得してデータベースをセットアップするバッチスクリプトと結び付けました。また、ユーザータイプや管理者ユーザーなどのデフォルトデータを入力するクエリをいくつか追加しました。(これについてさらに詳しい情報が必要な場合は、何か投稿してください。スクリプトをアクセス可能な場所に置くことができます)

すべてのデータも保持する必要がある場合は、データベースのバックアップを保持し、Redgate を使用することをお勧めします (http://www.red-gate.com/) の製品を比較します。決して安くはありませんが、一銭たりとも価値があります。

まず、自分に合ったバージョン管理システムを選択する必要があります。

集中バージョン管理システム - ユーザーがファイルを操作する前/後にチェックアウト/チェックインする標準システムで、ファイルは単一の中央サーバーに保管されます。
分散バージョン制御システム - リポジトリがクローン化されているシステムで、各クローンは実際にはリポジトリの完全なバックアップであるため、サーバーがクラッシュした場合、ニーズに合った適切なシステムを選択した後、クローンリポジトリを使用して復元できます。、すべてのバージョン制御システムのコアであるリポジトリをセットアップする必要があります。これはすべて、次の記事で説明されています。 http://solutioncenter.apexsql.com/sql-server-source-control-part-i- Understanding-source-control-basics/

リポジトリ、および中央バージョン管理システムの場合は作業フォルダーを設定した後、次の内容を読み取ることができます。この記事. 。以下を使用して開発環境でソース管理をセットアップする方法を示します。

MSSCCI プロバイダー経由の SQL Server Management Studio、
Visual Studio と SQL Server データツール
サードパーティツール ApexSQL ソース管理

Red Gate では、次のようなツールを提供しています。 SQLソース管理, 、SQL Compare テクノロジを使用して、データベースを TFS または SVN リポジトリにリンクします。このツールは SSMS に統合されており、オブジェクトをコミットできるようになった点を除いて、通常どおりに作業できるようになります。

移行ベースのアプローチ (自動展開により適しています) の場合、以下を提供します。 SQL変更の自動化 (以前は ReadyRoll と呼ばれていました)、一連の増分スクリプトを Visual Studio プロジェクトとして作成および管理します。

SQL ソース管理では、静的データテーブルを指定できます。これらは INSERT ステートメントとしてソース管理に保存されます。

テストデータについて話している場合は、ツールまたは定義した展開後のスクリプトを使用してテストデータを生成するか、単に運用環境のバックアップを開発環境に復元することをお勧めします。

Liquibase (http://www.liquibase.org/）。ツール自体を使用しない場合でも、データベース変更管理やリファクタリングの概念を非常にうまく処理できます。

RedGate ツールを推奨したすべての人に +1 を付けます。追加の推奨事項と注意事項も含まれます。

SqlCompare には、適切に文書化された API もあります。たとえば、チェックイン時にソース管理されたスクリプトフォルダーを CI 統合テストデータベースと同期するコンソールアプリを作成して、誰かがスクリプトフォルダーからスキーマへの変更をチェックインすると、一致するアプリケーションとともに自動的にデプロイされるようにすることができます。コード変更。これは、ローカル DB の変更を共有開発 DB に伝播することを忘れがちな開発者 (私たちの約半数だと思います:) とのギャップを埋めるのに役立ちます。

注意点としては、スクリプト化されたソリューションを使用するかどうかにかかわらず、RedGate ツールは十分にスムーズであるため、抽象化の基礎となる SQL の現実性を忘れがちであるということです。テーブル内のすべての列の名前を変更すると、SqlCompare では古い列を新しい列にマップする方法がなくなり、テーブル内のすべてのデータが削除されます。警告が生成されますが、それを無視してクリックしている人を見たことがあります。ここで一般的なポイントとして挙げておきたいのは、DB のバージョン管理とアップグレードを自動化できるのは今のところのみであるということです。抽象化には非常に漏れが生じます。

を使用しております DBゴースト SQL データベースを管理するため。次に、バージョン管理に新しいデータベースを構築するためのスクリプトを配置すると、新しいデータベースが構築されるか、既存のデータベースがバージョン管理のスキーマにアップグレードされます。こうすることで、変更スクリプトの作成について心配する必要がなくなります (ただし、たとえば列のデータ型を変更し、データを変換する必要がある場合には、変更スクリプトを作成することは可能です)。

VS 2010 では、データベースプロジェクトを使用します。

データベースをスクリプト化する
DBサーバーでスクリプトまたは直接変更を加える
データ> Schema Compareを使用して同期します

完璧な DB バージョン管理ソリューションを作成し、DB の同期を簡単にします。

データベーススクリプトを変更スクリプトとともにバージョン管理に保存して、所有しているデータベースを 1 つアップグレードできるようにするのは良い方法です。また、すべての変更スクリプトを適用しなくても完全なデータベースを作成できるように、さまざまなバージョンのスキーマを保存することもできます。手動作業を必要としないように、スクリプトの処理は自動化する必要があります。

共有データベースを使用せず、開発者ごとに個別のデータベースを用意することが重要だと思います。そうすることで、開発者は他の開発者から独立してテストケースと開発フェーズを作成できます。

自動化ツールには、どのデータベースがどのような開発状態にあるか、どのテーブルにバージョン管理可能なデータが含まれているかなどを示すデータベースメタデータを処理する手段が必要です。

移行ソリューションを検討することもできます。これらを使用すると、C# コードでデータベーススキーマを指定し、MSBuild を使用してデータベースのバージョンをロールアップおよびロールダウンできます。

現在使用していますデータベースアップ, 、そしてそれはうまくいきました。

ターゲット環境や制約について具体的に言及していないため、これが完全に当てはまるわけではない可能性があります...しかし、進化する DB スキーマを効果的に追跡する方法を探していて、Ruby を使用することに抵抗がないのであれば、ActiveRecord の移行が最適です。

移行では、Ruby DSL を使用してデータベース変換をプログラム的に定義します。各変換は適用または (通常は) ロールバックできるため、いつでも DB スキーマの別のバージョンにジャンプできます。これらの変換を定義するファイルは、他のソースコードと同様にバージョン管理にチェックインできます。

移行は一部であるため、アクティブレコード, 、通常、フルスタックの Rails アプリで使用されます。ただし、最小限の労力で、Rails から独立して ActiveRecord を使用できます。見るここ Rails の外で AR の移行を使用する場合のより詳細な処理については、こちらを参照してください。

すべてのデータベースはソースコード管理下にある必要があります。不足しているのは、すべてのデータベースオブジェクト (および「構成データ」) を自動的にファイルにスクリプト化し、任意のソース管理システムに追加できるツールです。SQL Server を使用している場合、私の解決策はここにあります: http://dbsourcetools.codeplex.com/ 。楽しむ。- ネイサン。

それは簡単です。

基本プロジェクトの準備ができたら、完全なデータベーススクリプトを作成する必要があります。このスクリプトは SVN にコミットされます。最初のバージョンです。
その後、すべての開発者が変更スクリプト (ALTER...、新しいテーブル、sproc など) を作成します。
現在のバージョンが必要な場合は、新しい変更スクリプトをすべて実行する必要があります。
アプリが実稼働環境にリリースされると、1 に戻ります (ただし、もちろんその後のバージョンになります)。

Nant は、これらの変更スクリプトの実行を支援します。:)

そして覚える。規律があればすべてがうまくいきます。データベースの変更がコミットされるたびに、コード内の対応する関数もコミットされます。

小規模なデータベースがあり、全体をバージョン管理したい場合は、このバッチスクリプト役立つかもしれません。MSSQL データベース MDF ファイルを切り離し、圧縮し、Subversion にチェックインします。

主にスキーマのバージョン管理が必要で、少量の参照データだけが必要な場合は、おそらく次のように使用できます。亜音速移行それに対処するために。利点は、特定のバージョンに簡単に移行できることです。

ソースコード管理システムへのダンプを少し速くするには、sysobjects のバージョン情報を使用して、前回からどのオブジェクトが変更されたかを確認できます。

設定： 段階的にチェックする各データベースにテーブルを作成し、最後にチェックしたときのバージョン情報を保持します (最初の実行では空です)。データ構造全体を再スキャンする場合は、このテーブルをクリアします。

IF ISNULL(OBJECT_ID('last_run_sysversions'), 0) <> 0 DROP TABLE last_run_sysversions
CREATE TABLE last_run_sysversions (
    name varchar(128), 
    id int, base_schema_ver int,
    schema_ver int,
    type char(2)
)

通常の実行モード: この SQL の結果を取得して、関心のあるものだけの SQL スクリプトを生成し、選択したソース管理に入れることができます。

IF ISNULL(OBJECT_ID('tempdb.dbo.#tmp'), 0) <> 0 DROP TABLE #tmp
CREATE TABLE #tmp (
    name varchar(128), 
    id int, base_schema_ver int,
    schema_ver int,
    type char(2)
)

SET NOCOUNT ON

-- Insert the values from the end of the last run into #tmp
INSERT #tmp (name, id, base_schema_ver, schema_ver, type) 
SELECT name, id, base_schema_ver, schema_ver, type FROM last_run_sysversions

DELETE last_run_sysversions
INSERT last_run_sysversions (name, id, base_schema_ver, schema_ver, type)
SELECT name, id, base_schema_ver, schema_ver, type FROM sysobjects

-- This next bit lists all differences to scripts.
SET NOCOUNT OFF

--Renamed.
SELECT 'renamed' AS ChangeType, t.name, o.name AS extra_info, 1 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id
WHERE o.name <> t.name /*COLLATE*/
AND o.type IN ('TR', 'P' ,'U' ,'V')
UNION 

--Changed (using alter)
SELECT 'changed' AS ChangeType, o.name /*COLLATE*/, 
       'altered' AS extra_info, 2 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id 
WHERE (
   o.base_schema_ver <> t.base_schema_ver
OR o.schema_ver      <> t.schema_ver
)
AND  o.type IN ('TR', 'P' ,'U' ,'V')
AND  o.name NOT IN ( SELECT oi.name 
         FROM sysobjects oi INNER JOIN #tmp ti ON oi.id = ti.id
         WHERE oi.name <> ti.name /*COLLATE*/
         AND oi.type IN ('TR', 'P' ,'U' ,'V')) 
UNION

--Changed (actually dropped and recreated [but not renamed])
SELECT 'changed' AS ChangeType, t.name, 'dropped' AS extra_info, 2 AS Priority
FROM #tmp t
WHERE    t.name IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
         WHERE NOT EXISTS (SELECT * FROM sysobjects oi
                           WHERE oi.id = ti.id))
AND  t.name IN ( SELECT oi.name /*COLLATE*/ FROM sysobjects oi
         WHERE NOT EXISTS (SELECT * FROM #tmp ti
                           WHERE oi.id = ti.id)
         AND   oi.type  IN ('TR', 'P' ,'U' ,'V'))
UNION

--Deleted
SELECT 'deleted' AS ChangeType, t.name, '' AS extra_info, 0 AS Priority
FROM #tmp t
WHERE NOT EXISTS (SELECT * FROM sysobjects o
                  WHERE o.id = t.id)
AND t.name NOT IN (  SELECT oi.name /*COLLATE*/ FROM sysobjects oi
         WHERE NOT EXISTS (SELECT * FROM #tmp ti
                           WHERE oi.id = ti.id)
         AND   oi.type  IN ('TR', 'P' ,'U' ,'V'))
UNION

--Added
SELECT 'added' AS ChangeType, o.name /*COLLATE*/, '' AS extra_info, 4 AS Priority
FROM sysobjects o
WHERE NOT EXISTS (SELECT * FROM #tmp t
                  WHERE o.id = t.id)
AND      o.type  IN ('TR', 'P' ,'U' ,'V')
AND  o.name NOT IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
         WHERE NOT EXISTS (SELECT * FROM sysobjects oi
                           WHERE oi.id = ti.id))
ORDER BY Priority ASC

注記： データベースで非標準の照合順序を使用している場合は、以下を置き換える必要があります。 /* COLLATE */ データベースの照合順序に合わせて。つまり COLLATE Latin1_General_CI_AI

私たちのアプリは複数の RDBMS にわたって動作する必要があるため、データベースに中立なデータベースを使用してスキーマ定義をバージョン管理に保存します。トルク形式 (XML)。また、次のように、データベースの参照データを XML 形式でバージョン管理します (「関係」は参照テーブルの 1 つです)。

  <Relationship RelationshipID="1" InternalName="Manager"/>
  <Relationship RelationshipID="2" InternalName="Delegate"/>
  etc.

次に、独自のツールを使用して、データベースのバージョン X からバージョン X + 1 に移行するために必要なスキーマのアップグレードと参照データのアップグレードスクリプトを生成します。

データベーススキーマを保存するのではなく、データベースへの変更を保存します。私たちが行うことは、データベースの任意のバージョン用の変更スクリプトを構築し、それを顧客のデータベースに適用できるように、スキーマの変更を保存することです。私は、スクリプトを読み取り、どの更新を適用する必要があるかを知ることができる、メインアプリケーションとともに配布されるデータベースユーティリティアプリを作成しました。また、必要に応じてビューやストアドプロシージャを更新するための十分な機能も備えています。

x64 プラットフォームに移行した後、SQL データベースのバージョンを設定する必要があり、古いバージョンが移行によって壊れました。SQLDMO を使用してすべての SQL オブジェクトをフォルダーにマッピングする C# アプリケーションを作成しました。

                Root
                    ServerName
                       DatabaseName
                          Schema Objects
                             Database Triggers*
                                .ddltrigger.sql
                             Functions
                                ..function.sql
                             Security
                                Roles
                                   Application Roles
                                      .approle.sql
                                   Database Roles
                                      .role.sql
                                Schemas*
                                   .schema.sql
                                Users
                                   .user.sql
                             Storage
                                Full Text Catalogs*
                                   .fulltext.sql
                             Stored Procedures
                                ..proc.sql
                             Synonyms*
                                .synonym.sql
                             Tables
                                ..table.sql
                                Constraints
                                   ...chkconst.sql
                                   ...defconst.sql
                                Indexes
                                   ...index.sql
                                Keys
                                   ...fkey.sql
                                   ...pkey.sql
                                   ...ukey.sql
                                Triggers
                                   ...trigger.sql
                             Types
                                User-defined Data Types
                                   ..uddt.sql
                                XML Schema Collections*
                                   ..xmlschema.sql
                             Views
                                ..view.sql
                                Indexes
                                   ...index.sql
                                Triggers
                                   ...trigger.sql

次に、アプリケーションは新しく書き込まれたバージョンと SVN に保存されているバージョンを比較し、相違がある場合は SVN を更新します。SQL にそれほど多くの変更を加えないため、プロセスを毎晩 1 回実行すれば十分であると判断しました。これにより、関心のあるすべてのオブジェクトに対する変更を追跡できるほか、重大な問題が発生した場合には完全なスキーマを再構築することができます。

このアプリは少し前に書きましたが、 http://sqlschemasourcectrl.codeplex.com/ これにより、MSFT SQL データベースが必要なだけスキャンされ、オブジェクト (テーブル、ビュー、プロシージャ、関数、SQL 設定) が SVN に自動的にダンプされます。まるで魔法のように機能します。Unfuddle と一緒に使用しています (チェックイン時にアラートを受け取ることができます)

一般的な解決策は、必要に応じてデータベースをダンプし、それらのファイルをバックアップすることです。

開発プラットフォームによっては、オープンソースのプラグインが利用できる場合があります。これを行うために独自のコードをローリングすることは、通常は非常に簡単です。

注記：データベースダンプをバージョン管理に入れるのではなく、バックアップすることもできます。バージョン管理ではファイルが急速に巨大化し、ソース管理システム全体が遅くなる可能性があります (今、CVS の恐ろしい話を思い出しています)。

Team Foundation Server の使用を開始したばかりです。データベースが中規模の場合、Visual Studio には、組み込みの比較、データ比較、データベースリファクタリングツール、データベーステストフレームワーク、さらにはデータ生成ツールとの優れたプロジェクト統合がいくつかあります。

ただし、このモデルは、非常に大規模なデータベースやサードパーティのデータベース (オブジェクトを暗号化する) にはあまり適合しません。したがって、カスタマイズしたオブジェクトのみを保存するようにしました。Visual Studio / Team Foundation サーバーは、そのために非常にうまく機能します。

TFSデータベースのチーフアーチ。ブログ

MS TFS サイト

私はESVの回答に同意します。まさにその理由から、長いサイドアウトのソースコードを維持できる非常に単純なファイルでデータベースの更新を維持できるようにするために、少し前に小さなプロジェクトを開始しました。これにより、開発者だけでなく、UAT や運用環境も簡単に更新できます。このツールは SQL Server と MySql 以外で動作します。

プロジェクトのいくつかの機能:

スキーマの変更を許可します
バリューツリーの追加を許可します
個別のテストデータの挿入を許可します。UAT
ロールバックのオプションを許可します (自動化されていません)
SQL サーバーと Mysql のサポートを維持します
1 つの簡単なコマンドで既存のデータベースをバージョン管理にインポートする機能があります (SQL サーバーのみ ...まだmysqlに取り組んでいます）

コードは Google コードでホストされています。詳細については、Google コードを確認してください。

http://code.google.com/p/databaseversioncontrol/

少し前に、DMO と VSS オブジェクトを使用して、データベース全体をスクリプト化して VSS に移行する VB bas モジュールを見つけました。VBスクリプトにして投稿しましたここ. 。VSS 呼び出しを簡単に取り出し、DMO を使用してすべてのスクリプトを生成し、VBScript を呼び出す同じバッチファイルから SVN を呼び出してそれらをチェックインできますか?

デイブ・J

また、データベース拡張プロパティファミリのプロシージャを介して保存されたデータベース内のバージョンも使用しています。私のアプリケーションには、バージョンステップごとにスクリプトがあります（つまり、1.1 から 1.2 に移動)。デプロイされると、現在のバージョンを確認し、アプリの最後のバージョンに達するまでスクリプトを 1 つずつ実行します。直接の「最終」バージョンを持つスクリプトはなく、クリーンな DB にデプロイする場合でも、一連のアップグレード手順を介してデプロイが行われます。

ここで付け加えておきたいのは、2 日前に MS キャンパスで、新しい今後の VS DB エディションに関するプレゼンテーションを見てきたということです。プレゼンテーションは特にこのトピックに焦点を当てたもので、私はびっくりしました。ぜひチェックしてみてください。新しい機能は、T-SQL スクリプトでのスキーマ定義の保持 (CREATE)、デプロイメントスキーマと定義されたスキーマを比較するランタイムデルタエンジン、デルタ ALTER の実行、およびソースコード統合との統合に重点が置かれています。自動ビルドドロップのための MSBUILD 継続的統合も含まれます。ドロップには、新しいファイルタイプである .dbschema ファイルが含まれており、これを展開サイトに取り込むことができ、コマンドラインツールで実際の「デルタ」を実行して展開を実行できます。このトピックに関するブログエントリには、VSDE ダウンロードへのリンクが含まれています。ぜひチェックしてください。 http://rusanu.com/2009/05/15/version-control-and-your-database/

これは非常に古い質問ですが、今でも多くの人がこの問題を解決しようとしています。彼らがしなければならないのは、Visual Studio データベースプロジェクトについて調べることだけです。これがなければ、データベース開発は非常に弱々しく見えます。コードの編成から展開、バージョン管理に至るまで、すべてが簡素化されます。

私の経験では、解決策は 2 つあります。

開発中に複数の開発者によって行われた開発データベースへの変更を処理する必要があります。
顧客サイトでデータベースのアップグレードを処理する必要があります。

#1 を処理するには、強力なデータベースの差分/マージツールが必要です。最適なツールは、未処理の競合を手動で解決できる一方で、可能な限り自動マージを実行できる必要があります。

完璧なツールは、BASE データベースに対して THEIRS データベースと MINE データベースに加えられた変更を考慮した 3 方向マージアルゴリズムを使用してマージ操作を処理する必要があります。

私は SQLite データベースの手動マージサポートを提供する商用ツールを作成しました。現在、SQLite の 3 方向マージアルゴリズムのサポートを追加しています。でチェックしてください http://www.sqlitecompare.com

#2 に対処するには、アップグレードフレームワークを導入する必要があります。

基本的なアイデアは、既存の SQL スキーマから新しい SQL スキーマにアップグレードする方法を認識し、既存の DB インストールごとにアップグレードパスを構築できる自動アップグレードフレームワークを開発することです。

このテーマに関する私の記事をチェックしてください http://www.codeproject.com/KB/database/sqlite_upgrade.aspx 私が話していることの概要を理解するためです。

幸運を

リロン・レヴィ

DBGhost をチェックしてください http://www.innovartis.co.uk/. 。私は 2 年間自動化された方法で使用していますが、非常にうまく機能しています。これにより、データベースを除いて、Java または C のビルドとほぼ同じように DB ビルドを実行できるようになります。私の言っていることが分かるよね。

比較ツールを使用してデータベースのバージョン管理システムを即興で構築することをお勧めします。良い代替案としては、 xSQL スキーマの比較そして xSQL データ比較.

ここで、データベースのスキーマのみをバージョン管理下に置くことが目標の場合は、xSQL Schema Compare を使用してスキーマの xSQL スナップショットを生成し、これらのファイルをバージョン管理に追加するだけです。特定のバージョンに戻すか更新するには、データベースの現在のバージョンと宛先バージョンのスナップショットを比較するだけです。

残念ながら、データもバージョン管理下に置きたい場合は、xSQL Data Compare を使用してデータベースの変更スクリプトを生成し、バージョン管理に .sql ファイルを追加できます。これらのスクリプトを実行して、必要なバージョンに戻す/更新することができます。「元に戻す」機能の場合は、実行するとバージョン 3 をバージョン 2 と同じにする変更スクリプトを生成する必要があり、「更新」機能の場合はその逆を行う変更スクリプトを生成する必要があることに注意してください。

最後に、基本的なバッチプログラミングスキルがあれば、コマンドラインバージョンの xSQL Schema Compare および xSQL Data Compare を使用してプロセス全体を自動化できます。

免責事項:私はxSQLに所属しています。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow