本文へスキップ
IntoSQL ホーム

データベースを別のデータベースに変換

mysqldump、mariadb-dump、pg_dump、SSMS、SQL Developer、SQLcl のダンプか SQLite の .db ファイルをドロップすると、同じテーブル、キー、インデックス、データを持つ PostgreSQL、MySQL、MariaDB、SQLite、SQL Server、Oracle 用のスクリプトをダウンロードできます。すべての変更はレポートに記載され、ダンプがコンピューターの外に出ることはありません。

ファイル
sqlshop_2024.sqlサンプルファイル、5.1 KB
データベース

18 行を変換、修正 8 件、却下なし

表示

shop_2024.sql のテーブルMySQL 8.0.46 のダンプ · mysqldump で作成 · utf8mb4

  • customers8 行3
    7 列
    idbigint not null
    namevarchar(100) not null
    emailvarchar(150) not null
    countryvarchar(2) not null
    is_activeboolean not null
    signed_update
    created_attimestamptz(0) not null
  • orders10 行5
    9 列
    idbigint not null
    customer_idbigint not null
    statustext not null
    totalnumeric(10,2) not null
    itemsinteger not null
    ordered_attimestamp(0) not null
    shipped_attimestamp(0)
    notevarchar(255)
    updated_attimestamptz(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();

修正

  1. customers の "id" は符号なしのため、負でないことを確かめるチェック制約付きの bigint にしました。
  2. customers の "signed_up" は NULL を許可するようになりました。一部の値が保存できず、NULL になったためです。
  3. customers の "signed_up" のデフォルト値 0000‑00‑00 は PostgreSQL が受け付ける日付ではないため、列にデフォルト値はありません。
  4. orders の "customer_id" は符号なしのため、負でないことを確かめるチェック制約付きの bigint にしました。
  5. orders の "id" は符号なしのため、負でないことを確かめるチェック制約付きの bigint にしました。
  6. orders の "items" は符号なしのため、負でないことを確かめるチェック制約付きの integer にしました。
  7. orders の "status" の 1 行には、MySQL が無効な入力に対して保存する空の値があります。値のチェック制約はこの値を許可します。
  8. 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 にしました。 その日付に意味がある場合は、ダンプする前にソース側で実際の日付に置き換えてください。

ファイルはこのコンピューター上で変換され、アップロードされることはありません。

その他のサンプル:

すべてのデータベースの組み合わせ

行はダンプの変換元、列はスクリプトの変換先のデータベースです。各組み合わせには専用のページがあり、設定済みのコンバーター、適用されるルール、スクリプトの読み込み方法を掲載しています。

すべての組み合わせのデータ型

保持されるものとレポートされるもの

コンバーターはデータベースサーバーなしでダンプを直接読み、その内容からスクリプトを書き出します。各組み合わせのページには、適用されるルール (組み合わせごとに 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 から PostgreSQL へのページ

お使いのデータベースをエクスポート

コンバーターが読むのは実行中のサーバーではなくファイルです。各データベースは独自のツールでファイルを書き出します。

  • 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 でスクリプトを実行してください。