データベースを別のデータベースに変換
mysqldump、mariadb-dump、pg_dump、SSMS、SQL Developer、SQLcl のダンプか SQLite の .db ファイルをドロップすると、同じテーブル、キー、インデックス、データを持つ PostgreSQL、MySQL、MariaDB、SQLite、SQL Server、Oracle 用のスクリプトをダウンロードできます。すべての変更はレポートに記載され、ダンプがコンピューターの外に出ることはありません。
18 行を変換、修正 8 件、却下なし
shop_2024.sql のテーブルMySQL 8.0.46 のダンプ · mysqldump で作成 · utf8mb4
customers8 行3
7 列 id bigint not null name varchar(100) not null email varchar(150) not null country varchar(2) not null is_active boolean not null signed_up date created_at timestamptz(0) not null orders10 行5
9 列 id bigint not null customer_id bigint not null status text not null total numeric(10,2) not null items integer not null ordered_at timestamp(0) not null shipped_at timestamp(0) note varchar(255) updated_at timestamptz(0) not null
-- Written by IntoSQL from a MySQL dump. Load it with: psql -v ON_ERROR_STOP=1 -f <file>
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
SET check_function_bodies = false;
SET client_min_messages = warning;
SET synchronous_commit = off;
SET maintenance_work_mem = '512MB';
CREATE TABLE customers (
id bigint GENERATED BY DEFAULT AS IDENTITY NOT NULL,
name varchar(100) NOT NULL,
email varchar(150) NOT NULL,
country varchar(2) DEFAULT 'US' NOT NULL,
is_active boolean DEFAULT true NOT NULL,
signed_up date,
created_at timestamptz(0) DEFAULT CURRENT_TIMESTAMP NOT NULL,
CONSTRAINT customers_id_check CHECK (id >= 0)
);
CREATE TABLE orders (
id bigint GENERATED BY DEFAULT AS IDENTITY NOT NULL,
customer_id bigint NOT NULL,
status text DEFAULT 'pending' NOT NULL,
total numeric(10,2) NOT NULL,
items integer DEFAULT 1 NOT NULL,
ordered_at timestamp(0) NOT NULL,
shipped_at timestamp(0),
note varchar(255),
updated_at timestamptz(0) DEFAULT CURRENT_TIMESTAMP NOT NULL,
CONSTRAINT orders_id_check CHECK (id >= 0),
CONSTRAINT orders_customer_id_check CHECK (customer_id >= 0),
CONSTRAINT orders_status_check CHECK (status IN ('pending', 'paid', 'shipped', 'cancelled', '')),
CONSTRAINT orders_items_check CHECK (items >= 0)
);
COPY customers (id, name, email, country, is_active, signed_up, created_at) FROM stdin;
1 Ana Martínez ana@example.com MX t 2023-01-15 2023-01-15 10:24:00+00:00
2 Zoë Müller zoe@example.de DE t 2023-02-03 2023-02-03 08:11:42+00:00
3 José Peña jose@example.es ES f 2023-03-21 2023-03-21 19:05:17+00:00
4 李雷 lilei@example.cn CN t 2023-05-09 2023-05-09 02:40:00+00:00
5 Noah O'Brien noah@example.ie IE t \N 2023-06-30 14:00:00+00:00
6 Amélie Laurent amelie@example.fr FR t 2024-01-02 2024-01-02 09:30:00+00:00
7 Ravi Patel ravi@example.in IN f 2024-02-29 2024-02-29 23:59:59+00:00
8 Sofia Rossi 🌻 sofia@example.it IT t 2024-04-12 2024-04-12 12:12:12+00:00
\.
COPY orders (id, customer_id, status, total, items, ordered_at, shipped_at, note, updated_at) FROM stdin;
1 1 shipped 129.90 3 2024-03-01 10:00:00 2024-03-02 16:30:00 \N 2024-03-02 16:30:00+00:00
2 2 paid 54.00 1 2024-03-02 11:15:00 \N Gift wrap 🎁 2024-03-02 11:20:00+00:00
3 1 cancelled 12.50 1 2024-03-03 09:45:00 \N Customer changed their mind 2024-03-03 10:00:00+00:00
4 4 shipped 980.00 12 2024-03-05 02:10:00 2024-03-07 08:00:00 请小心轻放 2024-03-07 08:00:00+00:00
5 5 pending 45.75 2 2024-03-08 17:20:00 \N Leave at the door; ring twice 2024-03-08 17:20:00+00:00
6 6 shipped 310.40 5 2024-03-10 13:00:00 2024-03-11 09:00:00 Fragile: "glass" 2024-03-11 09:00:00+00:00
7 8 paid 76.20 2 2024-03-11 18:45:00 \N \N 2024-03-11 18:46:00+00:00
8 2 19.99 1 2024-03-12 08:00:00 \N Status lost in an old import 2024-03-12 08:00:00+00:00
9 3 shipped 64.00 2 2024-03-14 15:30:00 \N Shipping date never recorded 2024-03-15 10:00:00+00:00
10 7 paid 1499.00 1 2024-03-15 21:05:00 \N C:\\Users\\ravi\\invoice.pdf 2024-03-15 21:05:00+00:00
\.
-- Keys, indexes and constraints, after the rows so each builds once.
CREATE UNIQUE INDEX customers_pkey ON customers (id);
CREATE UNIQUE INDEX customers_uq_email ON customers (email);
CREATE UNIQUE INDEX orders_pkey ON orders (id);
CREATE INDEX orders_idx_customer ON orders (customer_id);
CREATE INDEX orders_idx_status_date ON orders (status, ordered_at);
ALTER TABLE customers ADD CONSTRAINT customers_pkey PRIMARY KEY USING INDEX customers_pkey;
ALTER TABLE customers ADD CONSTRAINT customers_uq_email UNIQUE USING INDEX customers_uq_email;
ALTER TABLE orders ADD CONSTRAINT orders_pkey PRIMARY KEY USING INDEX orders_pkey;
ALTER TABLE orders ADD CONSTRAINT fk_orders_customer FOREIGN KEY (customer_id) REFERENCES customers (id) NOT VALID;
DO $f$ BEGIN
ALTER TABLE orders VALIDATE CONSTRAINT fk_orders_customer;
EXCEPTION WHEN foreign_key_violation THEN
RAISE WARNING 'foreign key % has rows without a parent: it stays NOT VALID, and new rows are checked', 'fk_orders_customer';
END $f$;
SELECT setval(pg_get_serial_sequence('customers', 'id'), LEAST(GREATEST(COALESCE((SELECT max(id) FROM customers)::numeric, 0) + 1, 1001), 9223372036854775807)::bigint, false);
COMMENT ON TABLE customers IS 'People who bought at least once';
SELECT setval(pg_get_serial_sequence('orders', 'id'), LEAST(GREATEST(COALESCE((SELECT max(id) FROM orders)::numeric, 0) + 1, 5001), 9223372036854775807)::bigint, false);
CREATE FUNCTION orders_updated_at_on_update() RETURNS trigger LANGUAGE plpgsql AS $f$
BEGIN
IF NEW IS DISTINCT FROM OLD AND NEW.updated_at IS NOT DISTINCT FROM OLD.updated_at THEN
NEW.updated_at := CURRENT_TIMESTAMP;
END IF;
RETURN NEW;
END
$f$;
CREATE TRIGGER orders_updated_at_on_update BEFORE UPDATE ON orders FOR EACH ROW EXECUTE FUNCTION orders_updated_at_on_update();
修正
- customers の "id" は符号なしのため、負でないことを確かめるチェック制約付きの bigint にしました。
- customers の "signed_up" は NULL を許可するようになりました。一部の値が保存できず、NULL になったためです。
- customers の "signed_up" のデフォルト値 0000‑00‑00 は PostgreSQL が受け付ける日付ではないため、列にデフォルト値はありません。
- orders の "customer_id" は符号なしのため、負でないことを確かめるチェック制約付きの bigint にしました。
- orders の "id" は符号なしのため、負でないことを確かめるチェック制約付きの bigint にしました。
- orders の "items" は符号なしのため、負でないことを確かめるチェック制約付きの integer にしました。
- orders の "status" の 1 行には、MySQL が無効な入力に対して保存する空の値があります。値のチェック制約はこの値を許可します。
- orders の "updated_at" は更新のたびに現在時刻に変わります。PostgreSQL ではトリガーがこれを行います。
確認が必要
- customers の "signed_up" にある 1 個の値は、0000‑00‑00 のようなゼロ日付または存在しない日付で、PostgreSQL では保存できないため NULL にしました。 その日付に意味がある場合は、ダンプする前にソース側で実際の日付に置き換えてください。
- orders の "shipped_at" にある 1 個の値は、0000‑00‑00 00:00:00 のようなゼロ日付または存在しない日付で、PostgreSQL では保存できないため NULL にしました。 その日付に意味がある場合は、ダンプする前にソース側で実際の日付に置き換えてください。
ファイルはこのコンピューター上で変換され、アップロードされることはありません。
その他のサンプル:
すべてのデータベースの組み合わせ
行はダンプの変換元、列はスクリプトの変換先のデータベースです。各組み合わせには専用のページがあり、設定済みのコンバーター、適用されるルール、スクリプトの読み込み方法を掲載しています。
- MySQL
- MariaDB
- PostgreSQL
- SQL Server
- SQLite
- Oracle
保持されるものとレポートされるもの
コンバーターはデータベースサーバーなしでダンプを直接読み、その内容からスクリプトを書き出します。各組み合わせのページには、適用されるルール (組み合わせごとに 25 から 67 個) と、それぞれがレポートに書く行を掲載しています。
スクリプトに保持
- テーブルと列。それぞれ変換先で最も近い型になり、長さと精度も保たれます。
- 主キー、一意キー、外部キー、インデックス、デフォルト値。
- AUTO_INCREMENT、IDENTITY、serial の列。各行の ID が保たれ、カウンターはダンプの続きから進みます。
- すべての行。日付、小数、テキスト、バイナリ値はダンプのとおりです。
レポートに記載
- 変換先がそのまま保持できない値 (PostgreSQL での 0000-00-00 の日付など)。列と件数も記載します。
invalid_date_null - 変換先にない型 (ENUM や INET6 など) と、それぞれの変換後の型。
type_replaced - ビュー、トリガー、プロシージャ、関数、イベントを名前で記載。各データベース独自の言語で書かれるため、変換しません。
not_converted_objects - 文字セットとして無効なテキストと、すでに 4 バイト文字を失っているダンプ。
invalid_utf8_replaced
pgloader との比較
同じダンプを IntoSQL と pgloader 3.6.7 で変換して読み込み、1 台のマシン (SATA SSD 搭載の 10 コア i9-10900K) で 2026 年 10 月に測定しました。
- 2、-1、-5 を持つ TINYINT(1) 列: pgloader は警告なしに、すべてを true として読み込みます。IntoSQL は数値を保ち、レポートにその理由が書かれます。
- 'it's' というデフォルト値、バッククォートを含む名前のテーブル、空の値を持つ ENUM、24 時間を超える TIME を含むダンプ: pgloader は止まります。IntoSQL は変換して読み込みます。
- pgloader で読み込んだ結果では、主キー、一意キー、外部キー、IDENTITY が失われています。IntoSQL はすべて保持します。
- 3000 万行、5.3 GB のダンプ: pgloader は先に稼働中の MySQL への復元が必要で、それに 18 分かかり、その後デフォルト設定ではメモリ不足になります。IntoSQL はダンプを 10 秒で変換し、psql はスクリプトを約 3 分で読み込みます。
- MySQL 5.5 から 9、MariaDB 10.3 から 12 の 476 個のダンプを PostgreSQL 13 と 18 に読み込みました。読み込みエラーはなく、レポートに記載されずに変わった値もありません。
お使いのデータベースをエクスポート
コンバーターが読むのは実行中のサーバーではなくファイルです。各データベースは独自のツールでファイルを書き出します。
MySQL
mysqldump、mysqlpump、phpMyAdmin、Adminer のダンプ (.sql または .sql.gz)。--default-character-set=utf8mb4 --hex-blob --routines --triggers --events を付けると最も多く保持できます。
MySQL から PostgreSQL への移行ガイドMariaDB
mariadb-dump、mysqldump、phpMyAdmin、Adminer のダンプ (.sql または .sql.gz)。オプションは MySQL と同じです。
MariaDB から PostgreSQL への移行ガイドPostgreSQL
pg_dump または pg_dumpall のプレーンなダンプ。カスタム形式 (-Fc) は、サーバーなしで pg_restore -f dump.sql により変換できます。
PostgreSQL から MySQL への移行ガイドSQL Server
SSMS のスクリプトの生成で、スクリプトを作成するデータの種類を「スキーマとデータ」にして書き出したスクリプト。dbatools や mssql-scripter でも同じものが書き出せます。
SQL Server から PostgreSQL への移行ガイドSQLite
データベースファイルそのもの (.db、.sqlite、.sqlite3)、または sqlite3 app.db .dump が書き出す SQL。
SQLite から PostgreSQL への移行ガイドOracle
SQL Developer のデータベース・エクスポートか SQLcl が書き出す、DDL と Insert 文を含む .sql ファイル。exp や expdp の .dmp ファイルは、先にインポートしてエクスポートし直す必要があります。
Oracle から PostgreSQL への移行ガイド
データベース移行に関する質問
ここに答えがない場合は、お問い合わせページからご連絡ください。担当者が返信します。 お問い合わせページ
ダンプはアップロードされますか?
いいえ。コンバーターはブラウザ上で動作し、ダンプをディスクから少しずつ読み込むため、ダンプがコンピューターの外に出ることはありません。デスクトップアプリとコマンドラインも、お使いのコンピューター上で変換します。
ダンプはどのくらいの大きさまで扱えますか?
コンバーターはダンプ全体をメモリに保持しません。ファイルを範囲ごとに 2 回読み、読みながらスクリプトを書き出します。数 GB のダンプも、ブラウザ、デスクトップアプリ、コマンドラインで変換できます。
どのバージョンのダンプに対応していますか?
MySQL 5.5 から 9、MariaDB 10.3 から 12、PostgreSQL 10 以降、SQL Server 2017 以降、SQLite 3.0 以降、Oracle 11g 以降です。スクリプトを読み込めるバージョンは各組み合わせのページに記載しています。
実行中のデータベースサーバーは必要ですか?
いいえ。コンバーターはダンプファイルを直接読むので、変換元のデータベースを動かす必要はありません。スクリプトは psql、mysql、sqlcmd など、変換先の標準クライアントで読み込めます。
変換されないものは?
ビュー、トリガー、ストアドプロシージャ、関数、イベントは各データベース独自の言語で書かれるため、代わりにレポートに名前で記載します。テーブル、キー、インデックス、行はすべてスクリプトに入ります。
スクリプトをデータベースに直接読み込めますか?
デスクトップアプリと intosql load コマンドで、SQLite には無料で、PostgreSQL、MySQL、MariaDB には IntoSQL Pro で直接書き込めます。SQL Server と Oracle では、sqlcmd か sqlplus でスクリプトを実行してください。