データベースをバージョン管理下に置きたいです。
私は常にそこに少なくともいくつかのデータを入れたいと思っています ( alumbが言及しているように: ユーザーの種類と管理者)。また、パフォーマンス測定のために生成されたテスト データの大規模なコレクションが必要になることもよくあります。
データベースにバージョン管理を適用するにはどうすればよいですか?
質問する
106854 次
29 に答える
187
Martin Fowler は、このテーマに関する私のお気に入りの記事http://martinfowler.com/articles/evodb.htmlを書きました。alumbや他の人が提案するように、スキーマ ダンプをバージョン管理下に置かないことにしました。これは、運用データベースを簡単にアップグレードする方法が必要だからです。
1 つの実稼働データベース インスタンスを持つ Web アプリケーションの場合、次の 2 つの手法を使用します。
データベース アップグレード スクリプト
スキーマをバージョン N から N+1 に移行するために必要な DDL を含むシーケンス データベース アップグレード スクリプト。(これらはバージョン管理システムに入ります。) _version_history_ テーブル、次のようなもの
create table VersionHistory (
Version int primary key,
UpgradeStart datetime not null,
UpgradeEnd datetime
);
新しいバージョンに対応するアップグレード スクリプトが実行されるたびに、新しいエントリを取得します。
これにより、存在するデータベース スキーマのバージョンを簡単に確認でき、データベース アップグレード スクリプトが 1 回だけ実行されるようになります。繰り返しますが、これらはデータベース ダンプではありません。むしろ、各スクリプトは、あるバージョンから次のバージョンに移行するために必要な変更を表しています。これらは、本番データベースを「アップグレード」するために適用するスクリプトです。
開発者サンドボックスの同期
- 本番データベースをバックアップ、サニタイズ、および縮小するスクリプト。本番 DB への各アップグレード後にこれを実行します。
- 開発者のワークステーションでバックアップを復元 (および必要に応じて微調整) するスクリプト。各開発者は、本番 DB への各アップグレード後にこのスクリプトを実行します。
警告: 私の自動テストは、スキーマは正しいが空のデータベースに対して実行されるため、このアドバイスはニーズに完全には適合しません。
于 2008-08-02T17:33:54.927 に答える
45
Red Gate の SQL Compare 製品は、オブジェクト レベルの比較を行い、そこから変更スクリプトを生成できるようにするだけでなく、[objectname].sql を 1 つ作成するだけで、オブジェクト タイプ別に編成されたフォルダー階層にデータベース オブジェクトをエクスポートすることもできます。これらのディレクトリ内のオブジェクトごとにスクリプトを作成します。オブジェクト型の階層は次のようになります。
\関数
\セキュリティ
\セキュリティ\ロール
\セキュリティ\スキーマ
\セキュリティ\ユーザー
\ストアド プロシージャ
\テーブル
変更を行った後にスクリプトを同じルート ディレクトリにダンプすると、これを使用して SVN リポジトリを更新し、各オブジェクトの実行履歴を個別に保持できます。
于 2008-08-26T07:23:51.707 に答える
39
まず、自分に適したバージョン管理システムを選択する必要があります。
集中型バージョン管理システム - ユーザーがファイルで作業する前後にチェックアウト/チェックインし、ファイルが単一の中央サーバーに保持される標準システム
分散バージョン管理システム - リポジトリのクローンが作成されるシステムで、各クローンは実際にはリポジトリの完全なバックアップであるため、サーバーがクラッシュした場合は、クローンされたリポジトリを使用して復元できます。必要に応じて適切なシステムを選択した後、すべてのバージョン管理システムのコアであるリポジトリをセットアップする必要があります。これはすべて、次の記事で説明されています: http://solutioncenter.apexsql.com/sql-server-source-control-part-i-understanding -ソース管理の基本/
リポジトリを設定した後、中央バージョン管理システムの場合は作業フォルダーを設定したら、この記事を読むことができます。以下を使用して、開発環境でソース管理をセットアップする方法を示します。
MSSCCI プロバイダー経由の SQL Server Management Studio、
Visual Studio と SQL Server データ ツール
- サードパーティ ツール ApexSQL ソース管理
于 2015-06-24T10:36:56.450 に答える
39
これは、開発を取り巻く「難しい問題」の 1 つです。私の知る限り、完全な解決策はありません。
データではなくデータベース構造のみを保存する必要がある場合は、データベースを SQL クエリとしてエクスポートできます。(Enterprise Manager で: データベースを右クリック -> SQL スクリプトを生成します。オプション タブで「オブジェクトごとに 1 つのファイルを作成する」を設定することをお勧めします) その後、これらのテキスト ファイルを svn にコミットし、svn の diff およびログ機能を利用できます。
これを、いくつかのパラメーターを使用してデータベースをセットアップするバッチ スクリプトと結び付けます。また、ユーザー タイプや管理者ユーザーなどのデフォルト データを入力するクエリをいくつか追加しました。(これに関する詳細情報が必要な場合は、何かを投稿してください。スクリプトをアクセス可能な場所に置くことができます)
すべてのデータも保持する必要がある場合は、データベースのバックアップを保持し、Redgate ( http://www.red-gate.com/ ) 製品を使用して比較を行うことをお勧めします。安くはありませんが、1ペニーの価値があります。
于 2008-08-01T19:28:25.447 に答える
25
Red Gateでは、SQL Compare テクノロジを使用してデータベースを TFS または SVN リポジトリにリンクするツールSQL Source Controlを提供しています。このツールは SSMS に統合されており、通常どおりに作業できますが、オブジェクトをコミットできるようになりました。
移行ベースのアプローチ (自動化された展開により適している) の場合、一連の増分スクリプトを Visual Studio プロジェクトとして作成および管理するSQL 変更自動化(以前は ReadyRoll と呼ばれていました) を提供しています。
SQL ソース管理では、静的データ テーブルを指定できます。これらは、INSERT ステートメントとしてソース管理に格納されます。
テスト データについて話している場合は、ツールまたは定義した配置後スクリプトを使用してテスト データを生成するか、単に運用バックアップを開発環境に復元することをお勧めします。
于 2010-07-01T09:10:15.997 に答える
22
Liquibase（http://www.liquibase.org/）をご覧になることをお勧めします。ツール自体を使用しない場合でも、データベースの変更管理またはリファクタリングの概念を適切に処理します。
于 2008-09-16T18:16:59.680 に答える
21
RedGate ツールを推奨しているすべての人に +1 を追加の推奨事項と注意事項とともに追加します。
SqlCompare には適切に文書化された API もあります。たとえば、チェックイン時にソース管理スクリプト フォルダーを CI 統合テスト データベースと同期するコンソール アプリを作成して、誰かがスクリプト フォルダーからスキーマへの変更をチェックインしたときに、これは、一致するアプリケーション コードの変更と共に自動的にデプロイされます。これは、ローカル データベースの変更を共有開発 DB に反映することを忘れている開発者とのギャップを埋めるのに役立ちます (私たちの約半分だと思います :))。
注意点は、スクリプト化されたソリューションまたはそれ以外の場合、RedGate ツールは十分にスムーズであるため、抽象化の根底にある SQL の現実を忘れがちです。テーブル内のすべての列の名前を変更すると、SqlCompare は古い列を新しい列にマップする方法がなく、テーブル内のすべてのデータを削除します。警告が生成されますが、それを過ぎてクリックする人を見てきました。これまでのところ、自動化できるのは DB のバージョン管理とアップグレードのみです。抽象化は非常に漏れやすいということです。
于 2008-10-15T09:44:04.590 に答える
16
DBGhostを使用してSQLデータベースを管理します。次に、スクリプトを配置してバージョン管理に新しいデータベースを構築します。これにより、新しいデータベースが構築されるか、既存のデータベースがバージョン管理のスキーマにアップグレードされます。そうすれば、変更スクリプトの作成について心配する必要はありません（ただし、たとえば、列のデータ型を変更してデータを変換する必要がある場合は、それでも可能です）。
于 2008-08-07T21:12:01.990 に答える
16
VS 2010 では、データベース プロジェクトを使用します。
- データベースをスクリプト化する
- スクリプトを変更するか、db サーバーで直接変更します
- [データ] > [スキーマ比較] を使用して同期します
完璧な DB バージョン管理ソリューションを作成し、DB の同期を簡単にします。
于 2011-02-25T20:18:05.107 に答える
12
移行ソリューションを見ることもできます。これらを使用すると、C# コードでデータベース スキーマを指定し、MSBuild を使用してデータベースのバージョンをロールアップおよびロールダウンできます。
私は現在DbUpを使用していますが、うまく機能しています。
于 2008-08-06T22:51:35.923 に答える
12
変更スクリプトを使用してデータベース スクリプトをバージョン管理に保存し、所有している任意のデータベースをアップグレードできるようにすることをお勧めします。また、すべての変更スクリプトを適用しなくても完全なデータベースを作成できるように、異なるバージョンのスキーマを保存することもできます。手動で作業する必要がないように、スクリプトの処理は自動化する必要があります。
共有データベースを使用するのではなく、開発者ごとに個別のデータベースを用意することが重要だと思います。これにより、開発者は他の開発者とは独立してテスト ケースと開発フェーズを作成できます。
自動化ツールには、データベース メタデータを処理する手段が必要です。これにより、どのデータベースがどの開発状態にあり、どのテーブルにバージョン管理可能なデータが含まれているかなどがわかります。
于 2008-09-24T06:11:22.250 に答える
10
すべてのデータベースはソースコード管理下にある必要があります。不足しているのは、すべてのデータベースオブジェクト（および「構成データ」）をファイルに自動的にスクリプト化するツールです。このファイルは、任意のソース管理システムに追加できます。SQL Serverを使用している場合、私の解決策はここにあります：http: //dbsourcetools.codeplex.com/。楽しむ。-ネイサン。
于 2009-07-07T12:58:34.487 に答える
10
ターゲット環境や制約に関する詳細について言及していないため、これは完全には当てはまらない可能性があります...しかし、進化するDBスキーマを効果的に追跡する方法を探していて、使用するという考えに反対しない場合Ruby、ActiveRecord の移行はまさにあなたの思い通りです。
移行では、Ruby DSL を使用してデータベース変換をプログラムで定義します。各変換を適用または (通常は) ロールバックできるため、任意の時点で別のバージョンの DB スキーマにジャンプできます。これらの変換を定義するファイルは、他のソース コードと同様にバージョン管理にチェックインできます。
移行はActiveRecordの一部であるため、通常はフルスタックの Rails アプリで使用されます。ただし、Rails とは関係なく、最小限の労力で ActiveRecord を使用できます。AR のマイグレーションを Rails 以外で使用する場合の詳細については、こちらを参照してください。
于 2008-08-02T17:54:50.687 に答える
9
簡単だ。
基本プロジェクトの準備ができたら、完全なデータベーススクリプトを作成する必要があります。このスクリプトはSVNにコミットされます。初版です。
その後、すべての開発者が変更スクリプト（ALTER ...、新しいテーブル、sprocなど）を作成します。
現在のバージョンが必要な場合は、すべての新しい変更スクリプトを実行する必要があります。
アプリが本番環境にリリースされると、1に戻ります（ただし、もちろん、それは連続バージョンになります）。
Nantは、これらの変更スクリプトの実行を支援します。:)
そして覚える。規律があるときはすべてうまくいきます。データベースの変更がコミットされるたびに、コード内の対応する関数もコミットされます。
于 2009-05-16T11:31:13.480 に答える
8
データベースが小さく、全体をバージョン管理したい場合は、このバッチスクリプトが役立つ場合があります。MSSQLデータベースのMDFファイルを切り離し、圧縮し、Subversionにチェックインします。
主にスキーマをバージョン管理する必要があり、参照データが少量しかない場合は、SubSonicMigrationsを使用してそれを処理できます。そこにある利点は、特定のバージョンに簡単に上下に移行できることです。
于 2008-08-07T21:21:01.050 に答える
8
アプリは複数の RDBMS で動作する必要があるため、データベースに中立なTorque形式 (XML) を使用して、スキーマ定義をバージョン管理に保存します。また、次のようにデータベースの参照データを XML 形式でバージョン管理します (「関係」は参照テーブルの 1 つです)。
<Relationship RelationshipID="1" InternalName="Manager"/>
<Relationship RelationshipID="2" InternalName="Delegate"/>
etc.
次に、独自のツールを使用して、データベースのバージョン X からバージョン X + 1 に移行するために必要なスキーマ アップグレードおよび参照データ アップグレード スクリプトを生成します。
于 2008-09-24T05:49:35.517 に答える
7
私はこのアプリを少し前に書きました。http://sqlschemasourcectrl.codeplex.com/は、MSFT SQL データベースを必要なだけ頻繁にスキャンし、オブジェクト (テーブル、ビュー、プロシージャ、関数、SQL 設定) を SVN に自動的にダンプします。魅力のように機能します。Unfuddle と一緒に使用します (これにより、チェックイン時にアラートを受け取ることができます)。
于 2010-09-23T02:35:41.337 に答える
7
データベース スキーマを保存するのではなく、データベースへの変更を保存します。私たちがしているのは、スキーマの変更を保存して、データベースの任意のバージョン用の変更スクリプトを作成し、それを顧客のデータベースに適用することです。そのスクリプトを読み取って、適用する必要がある更新を知ることができるメイン アプリケーションと共に配布されるデータベース ユーティリティ アプリを作成しました。また、必要に応じてビューやストアド プロシージャを更新するのに十分な機能も備えています。
于 2008-08-06T23:00:16.310 に答える
7
ソース コード管理システムへのダンプを少し速くするために、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
于 2008-09-24T12:53:48.757 に答える
6
一般的な解決策は、必要に応じてデータベースをダンプし、それらのファイルをバックアップすることです。
開発プラットフォームによっては、オープンソースのプラグインが利用できる場合があります。それを行うために独自のコードをローリングすることは、通常、かなり簡単です。
注: バージョン管理に入れる代わりに、データベース ダンプをバックアップすることをお勧めします。ファイルはバージョン管理で非常に高速になり、ソース管理システム全体が遅くなる可能性があります (現時点で、CVS の恐ろしい話を思い出しています)。
于 2008-08-03T01:49:58.983 に答える
6
私はESVの回答に同意します。まさにその理由で、データベースの更新を非常に単純なファイルで維持するのを助けるために、しばらく前に小さなプロジェクトを開始しました。これにより、開発者だけでなく、UAT および本番環境も簡単に更新できます。このツールは、SQL Server と MySQL で動作します。
プロジェクトの機能:
- スキーマの変更を許可します
- 値ツリーの作成を許可
- たとえば、個別のテストデータを挿入できます。UAT
- ロールバックのオプションを許可します (自動化されていません)
- SQL サーバーと MySQL のサポートを維持
- 1 つの簡単なコマンドで既存のデータベースをバージョン管理にインポートする機能があります (SQL サーバーのみ ... MySQL で動作中)
詳細については、コードを確認してください。
于 2011-02-24T18:28:51.967 に答える
6
x64 プラットフォームに移行した後、SQL データベースのバージョンを変更する必要がありましたが、移行によって古いバージョンが壊れてしまいました。SQLDMO を使用してすべての SQL オブジェクトをフォルダーにマップする C# アプリケーションを作成しました。
根
サーバー名
データベース名
スキーマ オブジェクト
データベーストリガー*
.ddltrigger.sql
機能
..関数.sql
安全
役割
アプリケーションの役割
.approle.sql
データベースの役割
.role.sql
スキーマ*
.schema.sql
ユーザー
.user.sql
保管所
全文カタログ*
.fulltext.sql
ストアド プロシージャ
..proc.sql
同義語*
.synonym.sql
テーブル
..表.sql
制約
...chkconst.sql
...defconst.sql
インデックス
...index.sql
キー
...fkey.sql
...pkey.sql
...ukey.sql
トリガー
...トリガー.sql
種類
ユーザー定義のデータ型
..uddt.sql
XML スキーマ コレクション*
..xmlschema.sql
ビュー
..view.sql
インデックス
...index.sql
トリガー
...トリガー.sql
アプリケーションは、新しく書き込まれたバージョンと SVN に保存されているバージョンを比較し、違いがあれば SVN を更新します。SQL にそれほど多くの変更を加えていないため、プロセスを 1 晩に 1 回実行するだけで十分であると判断しました。これにより、関心のあるすべてのオブジェクトへの変更を追跡でき、重大な問題が発生した場合に完全なスキーマを再構築できます。
于 2008-10-09T14:54:12.467 に答える
5
しばらく前に、DMO と VSS オブジェクトを使用して db 全体をオフにして VSS にスクリプト化する VB bas モジュールを見つけました。これを VB スクリプトに変換して、ここに投稿しました。VSS 呼び出しを簡単に取り出し、DMO を使用してすべてのスクリプトを生成し、VBScript を呼び出してそれらをチェックインする同じバッチ ファイルから SVN を呼び出すことができます。
于 2008-09-16T17:55:32.807 に答える
5
Team Foundation Server の使用を開始したばかりです。データベースが中規模の場合、ビジュアル スタジオには、組み込みの比較、データ比較、データベース リファクタリング ツール、データベース テスト フレームワーク、さらにはデータ生成ツールとの優れたプロジェクト統合がいくつかあります。
しかし、そのモデルは、(オブジェクトを暗号化する) 非常に大規模な、またはサード パーティのデータベースにはあまり適していません。そのため、カスタマイズしたオブジェクトのみを保存するようにしました。Visual Studio / Team Foundation Server は、そのために非常にうまく機能します。
于 2008-08-22T17:13:23.350 に答える
5
また、プロシージャのデータベース拡張プロパティ ファミリを介して格納されたデータベースのバージョンも使用しています。私のアプリケーションには、各バージョン ステップ (つまり、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/
于 2009-05-15T19:26:32.893 に答える
3
DBGhosthttp ://www.innovartis.co.uk/をチェックしてください。私は2年間自動化された方法で使用しました、そしてそれは素晴らしい働きをします。これにより、データベースを除いて、JavaまたはCビルドと同じようにDBビルドを実行できます。私の言っていることが分かるよね。
于 2009-11-02T22:17:17.307 に答える
3
私の経験では、解決策は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にあるこのテーマに関する私の記事をチェックして、私が話していることの概要を理解してください。
幸運を
リロン・レヴィ
于 2009-08-06T10:28:36.633 に答える
2
比較ツールを使用して、データベースのバージョン管理システムを即興で作成することをお勧めします。xSQL Schema CompareとxSQL Data Compareの 2 つが適切な代替手段です。
データベースのスキーマのみをバージョン管理下に置きたい場合は、xSQL Schema Compare を使用してスキーマの xSQL スナップショットを生成し、これらのファイルをバージョン管理に追加するだけです。次に、特定のバージョンに戻すまたは更新するには、データベースの現在のバージョンを目的のバージョンのスナップショットと比較します。
また、データをバージョン管理下にも置きたい場合は、xSQL Data Compare を使用してデータベースの変更スクリプトを生成し、.sql ファイルをバージョン管理に追加できます。その後、これらのスクリプトを実行して、必要なバージョンに戻す/更新することができます。「元に戻す」機能については、実行時にバージョン 3 をバージョン 2 と同じにする変更スクリプトを生成する必要があり、「更新」機能については、反対のことを行う変更スクリプトを生成する必要があることに注意してください。
最後に、いくつかの基本的なバッチ プログラミング スキルがあれば、xSQL Schema Compare および xSQL Data Compare のコマンド ライン バージョンを使用してプロセス全体を自動化できます。
免責事項: 私は xSQL に所属しています。
于 2017-01-10T16:16:55.723 に答える