Co je tento nástroj?
Naplnění testovací databáze, načtení exportu tabulky do databázové tabulky nebo migrace malé sady dat často začíná stejně: máte CSV soubor a potřebujete SQL. Tento nástroj parsuje váš CSV (s hlavičkovým řádkem jako názvy sloupců) a sestaví jeden příkaz INSERT INTO pokrývající každý datový řádek, připravený ke vložení do databázového klienta.
Textové hodnoty jsou obaleny jednoduchými uvozovkami s interními uvozovkami escapovanými zdvojením (takže O'Brien se stane O''Brien), což je standardní pravidlo escapování sdílené MySQL, PostgreSQL a SQLite. Prázdná buňka CSV je zapsána jako SQL klíčové slovo NULL místo prázdného řetězce — to je záměrná volba, protože prázdná buňka v tabulce obvykle znamená "žádná hodnota", ne "prázdný kus textu", a NULL je to, co většina schémat pro tento případ očekává.
Zda hodnota dostane uvozovky nebo zůstane holá, rozhoduje jednoduchá heuristika, ne skutečná detekce typu: pokud ořezaná buňka vypadá jako obyčejné celé nebo desetinné číslo (volitelně s vedoucím mínusem), zapíše se bez uvozovek; vše ostatní — včetně věcí, které jen připomínají čísla s dalšími znaky, jako telefonní čísla nebo PSČ s vedoucími nulami — se uvozovkuje jako text. To udržuje výstup poctivý: je to dobrý výchozí bod pro malý import, ne náhrada za validaci vašich dat proti skutečnému schématu tabulky před spuštěním.
Zdroj: Parsování CSV se řídí RFC 4180, nejbližší věcí formálnímu standardu CSV; zdvojování jednoduchých uvozovek pro escapování řetězců je sdílená konvence dokumentovaná MySQL, PostgreSQL a SQLite.
Proč ho používat?
- Vlastní název tabulky — nastavte cílovou tabulku jednou a každý řádek cílí na tuto tabulku.
- Správné escapování řetězců — jednoduché uvozovky uvnitř hodnot jsou zdvojené, takže se SQL nerozbije ani neuřízne.
- Předvídatelné zpracování NULL — prázdné buňky se stávají NULL místo prázdného řetězce, což odpovídá tomu, jak většina databází rozlišuje chybějící data.
- Běžná SQL syntaxe — forma INSERT INTO ... VALUES ... vygenerovaná zde funguje beze změny v MySQL, PostgreSQL a SQLite.
- 100% na straně klienta — vaše CSV data (která mohou obsahovat záznamy zákazníků nebo firemní data) se parsují a převádějí ve vašem prohlížeči a nikdy se nikam nenahrávají.
Jak se používá
- Vložte data CSV s hlavičkovým řádkem, např. name,age\nAlice,30\nBob,25.
- Zadejte název cílové tabulky (výchozí je my_table).
- Klikněte na "Generovat SQL".
- Zkopírujte příkaz INSERT INTO nebo ho stáhněte jako soubor .sql, poté ho spusťte proti vaší databázi.
Příklad
Vstup
name,age,city
Alice,30,
Bob,,NYCVýstup
INSERT INTO `my_table` (`name`, `age`, `city`)
VALUES
('Alice', 30, NULL),
('Bob', NULL, 'NYC');Všimněte si, že prázdné buňky se staly NULL (ne prázdnými řetězci) a číselně vypadající hodnota věku 30 zůstala bez uvozovek, zatímco každá textová hodnota byla uvozovkovaná.
Praktické tipy
- Naplnění lokální testovací databáze: exportujte malý vzorek jako CSV z tabulky, převeďte ho zde a spusťte příkaz INSERT proti své vývojové databázi.
- Vždy zkontrolujte typy sloupců před spuštěním vygenerovaného SQL proti skutečné tabulce — tento nástroj odvozuje číselné vs. textové hodnoty jednoduchou heuristikou, ne vaším skutečným schématem, takže sloupec integer očekávající specifický formát může potřebovat ruční úpravu.
- Pokud máte tisíce řádků, jediný víceřádkový příkaz INSERT, který tento nástroj generuje, je stále platné SQL, ale velmi velké příkazy mohou narazit na maximální velikost paketu databáze — pokud na tento limit narazíte, rozdělte CSV nejdřív na menší dávky.
Proč NULL a ne prázdný řetězec
Běžná chyba při ručním psaní skriptů CSV na SQL je zacházet s každou chybějící buňkou jako prázdným řetězcem ''. To je technicky platné SQL, ale obvykle neznamená to, co chcete: sloupec definovaný jako celé číslo '' rovnou odmítne, a i v textovém sloupci '' tiše znamená něco jiného než "tuto hodnotu neznáme" ve většině návrhů schémat a reportovacích dotazů (kontrola WHERE column IS NULL nebude odpovídat prázdným řetězcům, a naopak). Použití NULL pro prázdné buňky odpovídá sémantice, kterou očekává většina databází a ORM, a předchází chybám typu, když má číselný sloupec v některých řádcích náhodou chybějící hodnoty.
Časté dotazy
Funguje to s každou SQL databází?
Generovaná syntaxe — identifikátory v obrácených uvozovkách, textové hodnoty v jednoduchých uvozovkách, standardní INSERT INTO ... VALUES ... — je běžná napříč MySQL, PostgreSQL a SQLite. PostgreSQL striktně nevyžaduje obrácené uvozovky kolem identifikátorů (používá dvojité uvozovky, pokud je uvozovkování vůbec potřeba), ale identifikátory v obrácených uvozovkách jsou tam neškodné, pokud nemáte neobvyklé názvy sloupců, které se srazí s vyhrazenými slovy. Neexistuje žádný jednotný oficiální SQL standard, kterým by se to řídilo — jen syntaxe, která funguje beze změny napříč nejběžnějšími databázemi.
Proč se z prázdné buňky stane NULL místo prázdného řetězce ''?
Toto je záměrná designová volba: ve většině reálných exportů CSV znamená prázdná buňka, že hodnota je neznámá nebo neaplikovatelná, ne doslova prázdný kus textu. NULL je to, co většina databázových schémat pro tento případ očekává. Pokud váš případ použití skutečně potřebuje prázdné řetězce místo toho, budete muset vygenerované SQL pro tyto případy ručně upravit.
Jak nástroj rozhoduje, zda hodnota potřebuje uvozovky?
Je to jednoduchá heuristika, ne skutečná detekce typu: pokud ořezaná buňka obsahuje pouze číslice (s volitelným vedoucím mínusem a maximálně jednou desetinnou tečkou), zapíše se bez uvozovek jako číslo. Vše ostatní se uvozovkuje jako text. To znamená, že PSČ jako 00501 nebo telefonní číslo by bylo zpracováno jako text (protože nesplní přísný celočíselný vzor pouze v případě, že má další znaky — samotná vedoucí nula zde stále parsuje jako číselná, takže identifikátory jako PSČ a ID před spuštěním SQL dvakrát zkontrolujte).
Nahrávají se moje data někam?
Ne. Parsování i generování SQL probíhá v JavaScriptu ve vašem prohlížeči — nic se neposílá na server, což to dělá bezpečným pro použití s exportovanými zákaznickými nebo firemními záznamy.
Zvládne to hodnoty CSV obsahující čárky nebo uvozovky?
Ano. CSV se parsuje pomocí správného parseru pro uvozovkovaná pole, který rozumí čárkám, zalomení řádků a zdvojeným uvozovkám uvnitř uvozovkovaných polí — ne naivnímu rozdělení podle čárek — takže pole jako "Smith, John" se čte jako jedna hodnota, ne rozdělené do dvou sloupců.