Přesunutí databáze z PostgreSQL → MySQL

Kcko

EDIT: Vyřešeno (po vlastní ose)
1 den zkoumáním a hledáním nějaké „automatického“ řešení.
1,5h poloruční práce a data mám tam kde sem je chtěl mít 1:1.
======

Ahoj,
zkusím, a případně smažte pokud se to nehodí.

Potřebuji vzít databázi z PostgreSQL včetně všeho (tabulky a data) a hodit si ji do MySQL.
Nic co jsem zkoušel (všechny online tooly, nástroje jako MySqlWorkbench) mi moc nefungují, ty databáze jsou jiné, mají jiné sloupce, syntaxi atd…

Dostal jsem se zatím k postupu, kdy jsem si na locale rozjel PostGree, a z dumpu musím vyhodit všechny CONSTRAINT věci (což mi nevadí) , naimportuji a poté si udělám dump a musím upravit syntaxi z apostrofů na ' případně nechat názvy sloupců, tabulek atd neoslashované.

Je to dost otrava, ale jde to. (Dělám to přes HeidiSQL a PG4admin).

Nedělal to někdo, nepořadí nějaké nenásilné řešení? Program za 400$ nepotřebuji :-)

PS. Dá se nějak vypnout CONSTRAINT? Něco příšernýho?

Postupuji takto:

DROP TABLE IF EXISTS "album_group_rights";
CREATE TABLE "public"."album_group_rights" (
    "id_album" bigint NOT NULL,
    "id_group" bigint NOT NULL,
    "rights" bigint NOT NULL,
    CONSTRAINT "album_group_rights_pkey" PRIMARY KEY ("id_album", "id_group"),
    CONSTRAINT "album_group_rights_id_album_fkey" FOREIGN KEY (id_album) REFERENCES image_album(id_album) ON UPDATE RESTRICT ON DELETE RESTRICT NOT DEFERRABLE,
    CONSTRAINT "album_group_rights_id_group_fkey" FOREIGN KEY (id_group) REFERENCES group(id_group) ON UPDATE RESTRICT ON DELETE RESTRICT NOT DEFERRABLE
) WITH (oids = false);

Z toho udělám něco jako

DROP TABLE IF EXISTS album_group_rights;
CREATE TABLE public.album_group_rights (
    id_album bigint NOT NULL,
    id_group bigint NOT NULL,
    rights bigint NOT NULL
);

Nemá někdo lepší ozkoušené řešení?

Editoval Kcko (15. 9. 2021 9:27)

Marek Bartoš

Předtím než se začneš trápit přesunem bych měl otázku – proč? Používám obojí a nejraději bych všude měl postgres, mysql je proti němu za trest :D

Kcko

Marek Bartoš napsal(a):

Předtím než se začneš trápit přesunem bych měl otázku – proč? Používám obojí a nejraději bych všude měl postgres, mysql je proti němu za trest :D

Jak na to zareagovat :-)
Třeba proto, že s MySQL dělám celý život (docela dobře ji ovládám), dále protože nechci zkoumat jak se naše CMSko zachová s PostresSQL db a tak dále.
Myslel jsem si, že to bude snažší, ale je to docela pakárna.
Takže zpátky k původní otázce :)

Editoval Kcko (14. 9. 2021 13:50)

Kamil Valenta

Jenže představa, že se to při ignorovaných CONSTRAINT bude chovat stejně, nebo to bude alespoň trochu použitelné, je mylná.
Takže zpátky k Markově otázce :)
Pokud je to napsané pro PG, nechej to na PG. Pokud to potřebuješ zahrnout do jiné appky, která je v MySQL, tak se to bude muset přepsat. Můžeš ale narazit (třeba na partitioning) na věci, které v MySQL vůbec nejsou, nebo jsou pojaty zcela jinak. Obávám se, že neexistuje žádné „Find and Replace“ řešení. A pokud ano a appka se vůbec rozběhne, dostane výkonnostně na… to.

Kcko

Kamil Valenta napsal(a):

Jenže představa, že se to při ignorovaných CONSTRAINT bude chovat stejně, nebo to bude alespoň trochu použitelné, je mylná.
Takže zpátky k Markově otázce :)
Pokud je to napsané pro PG, nechej to na PG. Pokud to potřebuješ zahrnout do jiné appky, která je v MySQL, tak se to bude muset přepsat. Můžeš ale narazit (třeba na partitioning) na věci, které v MySQL vůbec nejsou, nebo jsou pojaty zcela jinak. Obávám se, že neexistuje žádné „Find and Replace“ řešení. A pokud ano a appka se vůbec rozběhne, dostane výkonnostně na… to.

Je to web napsaný v PHP na PostreSQL a já ted budu dělat zcela nový web a chci si ty data přehodit do MySQL, abych s tím mohl rozumně pracovat a udělat si pak migraci dat do svého DB modelu.

Nemyslím, že bych dělal něco nestandardního a skutečně nevím, proč bych se měl držet DB, kterou sem v životě nepoužil, kterou se učit nechci a kterou absolutně neznám, jen proto, že to použil někdo jiný předemnou (je to malý web pro pár desítek lidí).

A ty CONSTRAINT klíče drží jen integritu dat, což je mi stejně fuk, protože budu dělat migraci jen něčeho a pohlídám si, že na novém webu má být co tam skutečně má být.

Nevím jestli jsi s tím někdy dělal, ale je fakt problém vytvořit znovu vytvořit tabulky s nadef. cizími klíčemi; prot je mažu a data jsem si vyexportoval do CSV a jen si je už importnu do DB.

Pavel Kravčík

Na tyhle věci (nový systém, import odbc oracle) dělám „transfer“. Buď jednorázový nebo noční nálevy, výkonově v pohodě. Většinou jsou to starší systémy, které nejsou extra dobře napsané a časově, i do budoucna pro vývoj, vyjde lépe to prostě přepsat „ručně“ do své struktury a vykašlat se na současné řešení. Pokud to bude jednorázová věc, klidně bych vytvořil nějakou kopii v MySQL ručně (CSV, nálev) a nad tím napsal jednorázový skript, který to přefrká do tvé nové struktury.

Kcko

Pavel Kravčík napsal(a):

Na tyhle věci (nový systém, import odbc oracle) dělám „transfer“. Buď jednorázový nebo noční nálevy, výkonově v pohodě. Většinou jsou to starší systémy, které nejsou extra dobře napsané a časově, i do budoucna pro vývoj, vyjde lépe to prostě přepsat „ručně“ do své struktury a vykašlat se na současné řešení. Pokud to bude jednorázová věc, klidně bych vytvořil nějakou kopii v MySQL ručně (CSV, nálev) a nad tím napsal jednorázový skript, který to přefrká do tvé nové struktury.

Je to jednorázovka, jen s tím, že před finálním spuštěním naleju poslední aktuální data a pustím migraci v Nette.

Nemělo smysl se tím zaobírat víc, jediné co jsem udělal

Dump pouze tabulek u kterých sem vyházel FK a upravil datové typy (PostgreSQL vs MysSQL se v určitých typech liší včetně syntaxe – slashes vs backtick)
Pak jsem vyexportoval data a to samé (pouze syntax)
Import v HeidiSQL a bylo hotovo.

Nejvíc času mi zabralo zkoumání v čem se ta syntaxe liší a pak už jen práce s nahrazením. Bylo to skoro hned.