2

任意の SQL2003 準拠の RDBMS で同じデータベースを作成して埋めるために SQL2003 コードの一部を生成する mysqldump または同様のツールの呪文はありますか?

（私が今試しているのはMonetDBです）

4

4 に答える 4

3

DDL ステートメントは、本質的にデータベース ベンダー固有です。基本的な構造は同じですが、タイプ、インデックス、制約などを定義する方法については、ベンダーごとに独自の考え方があります。

一方、DML ステートメントはかなり移植性があります。したがって、私は提案します：

  • スキーマを取得するために、データなしでデータベースをダンプします (mysqldump --no-data)。
  • スキーマを他の DB にロードするために必要な変更を行います。これらは手動で行う必要があります (ただし、一部の検索/置換は可能です)。
  • 拡張挿入をオフにしてテーブルを作成せずにデータをダンプします (--extended-insert=0 --no-create-info)
  • 結果のスクリプトを他の DB に対して実行します。

これはあなたが望むことをするはずです。

ただし、アプリケーションを別のデータベース ベンダーに移植する場合は、他にも多くのことが必要になります。スキーマとデータの移動は簡単です。導入されたバグのチェック、さまざまな動作とパフォーマンスのテストは難しい部分です。

少なくとも、新しいデータベースでの有効性について、アプリケーション内のすべてのクエリをテストしてください。もっと多くのことをするのが理想的です。

于 2008-09-18T09:10:26.547 に答える
1

これはちょっと厳しいです。通常の型 (varchar、integer など) を持つ非常に単純な DB 構造を持っていない限り、移行ツールを作成することでおそらく最良の結果が得られるでしょう。Perl のような言語 (DBI 経由) では、これは非常に簡単です。このプログラムは基本的に、1 つのデータベースから読み取り、別のデータベースに挿入するエコー ループです。Google が認識しているこの種のコードの例があります。

データを移動するという明らかな問題は別として、一部のデータ型がどのように表現されるかという、より微妙な問題があります。たとえば、MS SQL の日時フィールドは、MySQL のものと同じ形式ではありません。BLOB などの他のデータ型は、RDBM によって容量が異なる場合があります。移植する前に、ターゲットDBシステムのデータ型定義を十分に理解していることを確認する必要があります。

もちろん、最後の問題は、アプリケーション レベルの SQL ステートメントを新しいシステムに対して機能させることです。私の仕事では、それが最も難しい部分です。日付の計算は特に DB 固有のように思われますが、引用規則などの煩わしいことは常に苛立たしいものです。

あなたのプロジェクトで頑張ってください。

于 2008-09-17T17:58:08.797 に答える
0

SQL Server 2000 または 2005 から、オブジェクトのスクリプトを生成できますが、それらが他の RDBMS にどれだけうまく転送されるかはわかりません。

于 2008-09-17T17:46:03.023 に答える
0

スクリプトの生成オプションは、おそらく最も簡単な方法です。ただし、いくつかのデータ型で検索/置換を行う必要があることは間違いありません。

于 2008-09-17T17:50:49.283 に答える