Extrémě rychlý "load SQL file"

dibi::connect();
dibi::loadFile('dump.sql');

dibi::loadFile('compress.zlib://dump.sql.gz');

Karma body: 21. Líbil se vám článek?

• 12. 1. 2008 Texy! – Nette – Dibi 7397x
• RSS komentářů k tomuto článku
• Vytisknout, odeslat [emailem], exportovat do [PDF].
• nahoru

Komentáře » přidat

1. [1] tark: nový

   Tohleto vypadá doopravdy skvěle, gratuluju

   Posláno 12. 1. 2008 v 10.12 | Odpovědět

2. [2] enoice: nový

   Bezvadné

   (zbytek smazán, dgx)

   Posláno 12. 1. 2008 v 11.48 | Odpovědět

3. [3] Tomik: nový

   Davide, díky moc! dibi se mi líbí čím dál tím více!

   Posláno 12. 1. 2008 v 17.41 | Odpovědět

4. [4] Dero: nový

   Výborné

   (zbytek smazán, dgx)

   Posláno 12. 1. 2008 v 18.26 | Odpovědět

5. [5] illi: nový

   při
   mysqldump
   jsou rozšířené inserty defaultní volbou, ne?
   teda aspoň mě to s nima generovalo a nedával jsem žádné zvláštní parametry.

   Posláno 12. 1. 2008 v 19.31 | Odpovědět

6. [6] Jakub Hejda: nový

   Tohle je pro mne důvod toho DIBILíka zkusit

   (zbytek smazán, amen) – to je nějaký místní pozdrav? 

   Posláno 12. 1. 2008 ve 20.24 | Odpovědět

7. [7] karel: nový

   Musím uznat, že to funguje skutečně výborně. Zkusil jsem import 71MB dumpu a trvalo to zhruba stejně rychle jako z příkazového řád­ku.

   Posláno 12. 1. 2008 ve 21.31 | Odpovědět

8. [8] Arcao: nový

   A co takhle použít perfektní phpMinAdmin Jakuba Vrány? Ten je na to přímo vhodný.

   Posláno 12. 1. 2008 ve 23.16 | Odpovědět

9. [9] Dundee: nový

   Tak to Dibi asi také zkusím. Kopírovat rozsáhlejší dumpy do PMA po pár set záznamech mi neuvěřitelně pilo krev :)

   Posláno 13. 1. 2008 ve 13.20 | Odpovědět

   Na komentář reagoval [16] Kcko

10. [10] Honza: nový

    Kdyby někdo potřeboval ten sql dump generovat ve skriptu

    Posláno 13. 1. 2008 ve 13.22 | Odpovědět

11. [11] mm-marek: nový

    huh tohle jsme potřeboval před měsícem… páral jsem se s tím až hrůza :(

    mám se taky něco připsat, abych měl toliko oceňované ohodnocení smazáno? :)

    poznámku o pochvale toho že se nette vypustí až ve finále jsem radši smazal :)

    Posláno 13. 1. 2008 v 19.39 | Odpovědět

12. [12] šťoura: nový

    V titulku článku je pravopisná chyba

    Posláno 13. 1. 2008 ve 20.59 | Odpovědět

    Na komentář reagoval [13] Honza

13. [13] Honza: nový

    [12] šťoura: stačí se začíst kousek dál

    Posláno 13. 1. 2008 ve 21.17 | Odpovědět

14. [14] Peet: nový

    Proc nebyl pouzit mysqlimport? Je jeste rychlejsi.

    Posláno 14. 1. 2008 v 8.25 | Odpovědět

    Na komentář reagoval [17] David Grudl

15. [15] RATMex B: nový

    Ona poznámka „je určen pro SQL dump ve formátu, který generují zmíněné nástroje“ je dosť klúčová. Práve kvôli tomu sa nedá tento import porovnávať s tým, čo robí phpMyAdmin, nakoľko jeho činnosť je ďaleko obsiahlejšia a všeobecnejšia (odstraňovanie komentárov, syntaktická analýza vstupu ako napr. ne-escape-nuté znaky v reťazcoch, syntaktická a sémantická analýza query pred vykonaním, a pod.).

    Priznávam, že spôsob akým to vykonáva môže byť neefektívny, ale dibi::loadFile() ho v žiadnom prípade nenahrádza.

    Posláno 14. 1. 2008 v 16.42 | Odpovědět

    Na komentář reagoval [17] David Grudl

16. [16] Kcko: nový

    [9] Dundee: A co takhle pres shell?

    Posláno 14. 1. 2008 v 19.22 | Odpovědět

    Na komentář reagoval [17] David Grudl

17. [17] David Grudl: nový

    [14] Peet: [16] Kcko: je snad zřejmé, že tahle funkce je určena pro případy, kdy není možné jiné utility použít. Což je případ „jen“ 99,99 % hostingů…

    [15] RATMex B: dá se porovnat velmi dobře: phpMyAdmin svůj vlastní výstup importuje 30 minut, dibi je hotové za 10 sekund (reálná čísla – z přenášení databáze iprotest.cz před pár dny). Nechci žádnou syntaktickou nebo sémantickou analýzu. A mimochodem, ani phpMyAdmin nic takového nedělá. Jen kontroluje, zda v dumpu nejsou volitelně zakázané příkazy USE, DROP apod.

    Požadavky na formát SQL dumpu jsou v podstatě jen dva:

    • nejsou dva příkazy na jednom řádku (tj. za příkazem následuje \n)
    • řetězce uvnitř SQL jsou escapovány funkcí mysql_(real_)es­cape_string (což by měla být samozřejmost)

    Posláno 14. 1. 2008 ve 22.02 | Odpovědět

    Na komentář reagoval [18] RATMex B

    Na komentář reagoval [20] Kcko

18. [18] RATMex B: nový

    [17] David Grudl: Pravda, porovnanie (koncového stavu) existuje, ale určite existuje aj vstup pre ktorý je výsledok: phpMyAdmin – 30 minút, dibi – import sa nevykonal. Rôzna činnosť obidvoch nástrojov robí porovnanie výsledkov irelevantným.
    Len vtedy ak oba nástroje na rovnaký vstup vykonajú tú istú činnosť (importujú resp. neimportujú tie isté údaje) bude mať časové porovnávanie ich behu nejakú výpovednú hodnotu.

    Posláno 15. 1. 2008 v 1.41 | Odpovědět

    Na komentář reagoval [19] David Grudl

19. [19] David Grudl: nový

    [18] RATMex B: ovšem to nic nemění na tom, že phpMyAdmin je tak neskutečně pomalý proto, že má importovací rutinu špatně napsanou.

    Posláno 15. 1. 2008 v 5.56 | Odpovědět

20. [20] Kcko: nový

    [17] David Grudl: Jasne.

    Nastesti tedy muj hosting patri do onoho skvostneho 0,01%

    Posláno 16. 1. 2008 ve 13.05 | Odpovědět

Tento článek byl uzavřen. Už není možné k němu přidávat komentáře ani hlasovat

Výtah na začátek článku na první komentář

Názory čtenářů v diskusích nejsou názory provozovatele webu, a ten za jejich obsah neodpovídá.