İçeriğe geç
IntoSQL ana sayfası

Bir veritabanını başka bir veritabanına dönüştürün

mysqldump, mariadb-dump, pg_dump, SSMS, SQL Developer veya SQLcl ile alınmış bir dökümü ya da bir SQLite .db dosyasını bırakın; aynı tablolar, anahtarlar, indeksler ve verilerle PostgreSQL, MySQL, MariaDB, SQLite, SQL Server veya Oracle için tek bir betik indirin. Her değişiklik bir raporda listelenir ve döküm bilgisayarınızdan hiç çıkmaz.

Dosyanız
sqlshop_2024.sqlÖrnek dosya, 5,1 kB
Veritabanınız

18 satır dönüştürüldü, 8 düzeltme, reddedilen yok

Göster

shop_2024.sql içindeki tablolarMySQL 8.0.46 dökümü · mysqldump ile yazıldı · utf8mb4

  • customers8 satır3
    7 sütun
    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 satır5
    9 sütun
    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();

Düzeltmeler

  1. customers tablosunun "id" sütunu işaretsiz; bu yüzden negatif olmadığını denetleyen bir CHECK ile bigint oldu.
  2. customers tablosunun "signed_up" sütunu artık NULL kabul ediyor: bazı değerleri saklanamadı ve NULL oldu.
  3. customers tablosundaki "signed_up" sütununun varsayılan değeri 0000‑00‑00, PostgreSQL'in kabul ettiği bir tarih değil; bu yüzden sütunun varsayılan değeri yok.
  4. orders tablosunun "customer_id" sütunu işaretsiz; bu yüzden negatif olmadığını denetleyen bir CHECK ile bigint oldu.
  5. orders tablosunun "id" sütunu işaretsiz; bu yüzden negatif olmadığını denetleyen bir CHECK ile bigint oldu.
  6. orders tablosunun "items" sütunu işaretsiz; bu yüzden negatif olmadığını denetleyen bir CHECK ile integer oldu.
  7. orders tablosundaki "status" sütununun 1 satırı MySQL'in geçersiz girişler için sakladığı boş değeri içeriyor; değerleri denetleyen CHECK buna izin veriyor.
  8. orders tablosunun "updated_at" sütunu her güncellemede geçerli zamana ayarlanıyor; PostgreSQL'de bunu bir tetikleyici yapıyor.

Kontrol edilmeli

  • customers tablosunun "signed_up" sütununda 0000‑00‑00 gibi 1 sıfır veya imkansız tarih var; PostgreSQL bunları saklayamaz, bu yüzden NULL yapıldı. Bu tarihler bir anlam taşıyorsa döküm almadan önce kaynakta gerçek tarihlerle değiştirin.
  • orders tablosunun "shipped_at" sütununda 0000‑00‑00 00:00:00 gibi 1 sıfır veya imkansız tarih var; PostgreSQL bunları saklayamaz, bu yüzden NULL yapıldı. Bu tarihler bir anlam taşıyorsa döküm almadan önce kaynakta gerçek tarihlerle değiştirin.

Dosyan bu bilgisayarda dönüştürülür ve asla yüklenmez.

Diğer örnekler:

Tüm veritabanı ikilileri

Satırlar dökümün geldiği veritabanı, sütunlar betiğin yazıldığı veritabanıdır. Her ikilinin, dönüştürücünün o ikili için ayarlandığı, uyguladığı kuralları ve betiğin nasıl yükleneceğini anlatan kendi sayfası vardır.

Her ikili için veri türleri

Neler korunur, neler raporlanır

Dönüştürücü, veritabanı sunucusu olmadan dökümün kendisini okur ve betiği içindekilerden yazar. Her ikilinin sayfası, uyguladığı kuralları, ikili başına 25 ile 67 arası, her birinin yazdığı rapor satırıyla birlikte listeler.

Betikte korunanlar

  • Tablolar ve sütunlar, her biri hedefteki en yakın tür, uzunluğu ve hassasiyetiyle.
  • Birincil, benzersiz ve yabancı anahtarlar, indeksler ve varsayılan değerler.
  • AUTO_INCREMENT, identity ve serial sütunları; her satırın id'si korunur ve sayaç dökümün bıraktığı yerden devam eder.
  • Her satır; tarihler, ondalıklar, metin ve ikili değerler dökümde olduğu gibi.

Raporda listelenenler

  • Hedefin olduğu gibi tutamadığı değerler, örneğin PostgreSQL'de 0000-00-00 tarihi, sütunu ve kaç tane olduğuyla.invalid_date_null
  • Hedefte olmayan türler, örneğin ENUM veya INET6, her birinin dönüştüğü türle birlikte.type_replaced
  • Görünümler, tetikleyiciler, yordamlar, fonksiyonlar ve olaylar, adlarıyla: her veritabanının kendi dilinde yazıldıkları için dönüştürülmezler.not_converted_objects
  • Karakter kümesinde geçerli olmayan metin ve 4 baytlık karakterlerini zaten kaybetmiş dökümler.invalid_utf8_replaced

pgloader ile karşılaştırmalı ölçüm

Aynı dökümler, Ekim 2026'da tek bir makinede (SATA SSD'li 10 çekirdekli bir i9-10900K) IntoSQL ve pgloader 3.6.7 ile dönüştürüldü ve yüklendi.

  • 2, -1 ve -5 içeren bir TINYINT(1) sütunu: pgloader her biri için uyarı vermeden true yükler. IntoSQL sayıları korur ve rapor nedenini söyler.
  • Varsayılan değeri 'it's' olan bir sütun, adında ters tırnak geçen bir tablo, boş değer içeren bir ENUM ve 24 saati aşan bir TIME içeren bir döküm: pgloader durur. IntoSQL dökümü dönüştürür ve yükler.
  • pgloader'ın yüklediği veride birincil, benzersiz ve yabancı anahtarlar ile kimlik sütunları kaybolmuştur. IntoSQL hepsini korur.
  • 30 milyon satırlık 5.3 GB'lık bir döküm: pgloader önce dökümün çalışan bir MySQL'e geri yüklenmesini ister, bu 18 dakika sürer, ardından varsayılan ayarlarıyla belleği tükenir. IntoSQL dökümü 10 saniyede dönüştürür, psql de betiği yaklaşık 3 dakikada yükler.
  • MySQL 5.5 ile 9 ve MariaDB 10.3 ile 12 arasından 476 döküm, PostgreSQL 13 ve 18'e yüklendi: hiç yükleme hatası yok ve hiçbir değer raporda bir satır olmadan değişmedi.
MySQL - PostgreSQL sayfası

Elinizdeki veritabanını dışa aktarın

Dönüştürücü çalışan bir sunucuyu değil, bir dosyayı okur. Her veritabanı bu dosyayı kendi araçlarıyla yazar:

  • MySQL

    mysqldump, mysqlpump, phpMyAdmin veya Adminer ile alınmış, .sql ya da .sql.gz biçiminde bir döküm. --default-character-set=utf8mb4 --hex-blob --routines --triggers --events en fazlasını korur.

    MySQL - PostgreSQL taşıma kılavuzu
  • MariaDB

    mariadb-dump, mysqldump, phpMyAdmin veya Adminer ile alınmış, .sql ya da .sql.gz biçiminde bir döküm; MySQL ile aynı seçeneklerle.

    MariaDB - PostgreSQL taşıma kılavuzu
  • PostgreSQL

    pg_dump veya pg_dumpall ile alınmış düz bir döküm. Özel bir arşiv (-Fc), sunucu olmadan pg_restore -f dump.sql ile düz döküme dönüşür.

    PostgreSQL - MySQL taşıma kılavuzu
  • SQL Server

    SSMS'in Generate Scripts aracının, Types of data to script seçeneği Schema and data olarak ayarlıyken yazdığı betik. dbatools ve mssql-scripter aynısını yazar.

    SQL Server - PostgreSQL taşıma kılavuzu
  • SQLite

    Veritabanı dosyasının kendisi (.db, .sqlite, .sqlite3) ya da sqlite3 app.db .dump komutunun yazdığı SQL.

    SQLite - PostgreSQL taşıma kılavuzu
  • Oracle

    SQL Developer'ın Database Export aracının veya SQLcl'in DDL ve Insert ifadeleriyle yazdığı .sql dosyası. exp veya expdp ile alınmış bir .dmp dosyasının önce içe aktarılıp yeniden dışa aktarılması gerekir.

    Oracle - PostgreSQL taşıma kılavuzu

Veritabanı taşıma hakkında sorular

Yanıtınızı bulamadınız mı? İletişim sayfasından bize yazın, bir kişi yanıt verir. İletişim sayfası

Dökümüm yükleniyor mu?

Hayır. Dönüştürücü tarayıcınızda çalışır ve dökümü diskinizden parça parça okur; böylece döküm bilgisayarınızdan hiç çıkmaz. Masaüstü uygulaması ve komut satırı da bilgisayarınızda dönüştürür.

Döküm ne kadar büyük olabilir?

Dönüştürücü dökümün tamamını asla bellekte tutmaz: dosyayı aralıklar halinde iki kez okur ve betiği ilerledikçe yazar. Birkaç gigabaytlık dökümler tarayıcıda, masaüstü uygulamasında ve komut satırıyla dönüştürülür.

Döküm hangi sürümlerden gelebilir?

MySQL 5.5 ile 9, MariaDB 10.3 ile 12 arası, PostgreSQL 10 ve sonrası, SQL Server 2017 ve sonrası, SQLite 3.0 ve sonrası ve Oracle 11g ve sonrası. Her ikilinin sayfası, betiğinin hangi sürümlerde yüklendiğini söyler.

Çalışan bir veritabanı sunucusuna ihtiyacım var mı?

Hayır. Dönüştürücü döküm dosyasının kendisini okur, bu yüzden kaynak veritabanının hiçbir yerde çalışması gerekmez. Betik, psql, mysql veya sqlcmd gibi hedefin kendi istemcisiyle yüklenir.

Neler dönüştürülmez?

Görünümler, tetikleyiciler, saklı yordamlar, fonksiyonlar ve olaylar her veritabanının kendi dilinde yazılır, bu yüzden bunun yerine raporda adlarıyla listelenir. Tablolar, anahtarlar, indeksler ve satırların hepsi betiktedir.

Betiği doğrudan veritabanıma yükleyebilir mi?

Masaüstü uygulaması ve intosql load komutu SQLite'a ücretsiz, PostgreSQL, MySQL ve MariaDB'ye ise IntoSQL Pro ile doğrudan yazar. SQL Server ve Oracle için betiği sqlcmd veya sqlplus ile çalıştırın.