CodeKitHub
JSON eszközök

CSV-SQL konverter

Utolsó frissítés:

Ahhoz, hogy egy CSV sort SQL-lé alakítsunk, minden oszlop egy értékké válik egy INSERT INTO utasításban — a számok idézőjel nélkül maradnak, a szöveg egyszeres idézőjelbe kerül, a belső idézőjelek megduplázva (O'Brien-ből O''Brien lesz), az üres cellák pedig NULL-lá válnak. Ez az eszköz ezt az átalakítást alkalmazza a teljes CSV fájlodra, teljes egészében a böngésződben.

Mi ez az eszköz?

Egy tesztadatbázis feltöltése, egy táblázat-export betöltése egy táblába, vagy egy kis adathalmaz migrálása gyakran ugyanúgy kezdődik: van egy CSV fájlod, és SQL-re van szükséged. Ez az eszköz elemzi a CSV-det (a fejlécsort oszlopnévként használva), és felépít egy INSERT INTO utasítást, amely minden adatsort lefed, beillesztésre készen egy adatbázis-kliensbe.

A szöveges értékek egyszeres idézőjelbe kerülnek, a belső idézőjelek megduplázva vannak escape-elve (így O'Brien-ből O''Brien lesz), ami a MySQL, PostgreSQL és SQLite közös, szabványos escape-szabálya. Egy üres CSV cella az SQL NULL kulcsszóként íródik, nem üres stringként — ez tudatos döntés, mivel egy táblázatban lévő üres cella általában azt jelenti, "nincs érték", nem pedig "egy üres szövegdarab", és a legtöbb séma ezt várja el.

Hogy egy érték idézőjelbe kerül-e vagy sem, egy egyszerű heurisztika dönti el, nem valódi típuskövetkeztetés: ha a levágott cella egyszerű egész vagy tizedes számnak néz ki (opcionálisan egy vezető mínuszjellel), idézőjel nélkül íródik; minden más — beleértve azokat is, amelyek csak hasonlítanak számokra extra karakterekkel, mint a telefonszámok vagy a vezető nullás irányítószámok — szövegként idézőjelbe kerül. Ez tartja a kimenetet őszintének: jó kiindulópont egy kisebb importhoz, de nem helyettesíti az adataid tényleges táblasémád szerinti ellenőrzését, mielőtt futtatnád.

Forrás: a CSV elemzés az RFC 4180-at követi, ami a formális CSV szabványhoz legközelebb áll; az egyszeres idézőjel megduplázása string escape-eléshez a MySQL, PostgreSQL és SQLite közös, dokumentált konvenciója.

Miért érdemes használni?

  • Egyedi táblanév — állítsd be egyszer a célt tábla nevét, és minden sor azt a táblát célozza meg.
  • Helyes string escape-elés — az értékeken belüli egyszeres idézőjelek megduplázva vannak, így az SQL nem törik el, és nem csonkul le.
  • Kiszámítható NULL kezelés — az üres cellák NULL-lá válnak üres string helyett, megfelelve annak, ahogy a legtöbb adatbázis megkülönbözteti a hiányzó adatot.
  • Gyakori SQL szintaxis — az itt generált INSERT INTO ... VALUES ... forma módosítás nélkül működik MySQL-ben, PostgreSQL-ben és SQLite-ban.
  • 100%-ban kliensoldali — a CSV adataid (amelyek ügyféladatokat vagy üzleti adatokat is tartalmazhatnak) a böngésződben elemződnek és alakulnak át, sosem kerülnek feltöltésre sehova.

Használati útmutató

  1. Illeszd be a CSV adatokat egy fejlécsorral, pl. name,age\nAlice,30\nBob,25.
  2. Add meg a cél tábla nevét (alapértelmezetten my_table).
  3. Kattints a "SQL generálása" gombra.
  4. Másold ki az INSERT INTO utasítást, vagy töltsd le .sql fájlként, majd futtasd az adatbázisod ellen.

Példa

Bemenet

name,age,city
Alice,30,
Bob,,NYC

Kimenet

INSERT INTO `my_table` (`name`, `age`, `city`)
VALUES
  ('Alice', 30, NULL),
  ('Bob', NULL, 'NYC');

Figyeld meg, hogy az üres cellák NULL-lá váltak (nem üres stringgé), és a számnak tűnő 30-as age érték idézőjel nélkül maradt, míg minden szöveges érték idézőjelbe került.

Gyakorlati tippek

  • Helyi tesztadatbázis feltöltése: exportálj egy kis mintát CSV-ként egy táblázatból, alakítsd át itt, és futtasd az INSERT utasítást a fejlesztői adatbázisod ellen.
  • Mindig nézd át az oszloptípusokat, mielőtt a generált SQL-t egy valódi tábla ellen futtatnád — ez az eszköz egy egyszerű heurisztikával, nem a tényleges sémád alapján következtet a szám kontra szöveg típusra, így egy adott formátumot váró egész oszlop kézi módosítást igényelhet.
  • Ha több ezer sorod van, az ezen eszköz által generált egyetlen, több sort tartalmazó INSERT utasítás továbbra is érvényes SQL, de nagyon nagy utasítások elérhetik az adatbázis maximális csomagméretét — oszd fel a CSV-t kisebb kötegekre, ha ebbe a korlátba ütközöl.

Miért NULL, és nem üres string

Egy gyakori hiba a kézzel írt CSV-SQL szkripteknél az, hogy minden hiányzó cellát üres stringként '' kezelnek. Ez technikailag érvényes SQL, de általában nem azt jelenti, amit szeretnél: egy egész számként definiált oszlop kereken elutasítja a ''-t, és még egy szöveges oszlopban is a '' csendben mást jelent, mint "nem ismerjük ezt az értéket" a legtöbb sématervben és riportáló lekérdezésben (egy WHERE oszlop IS NULL ellenőrzés nem fog egyezni üres stringekkel, és fordítva sem). A NULL használata az üres cellákhoz megfelel annak a szemantikának, amit a legtöbb adatbázis és ORM elvár, és elkerüli a típushibákat, amikor egy numerikus oszlopnak véletlenül hiányzó értékei vannak néhány sorban.

Gyakori kérdések

Ez minden SQL adatbázissal működik?

A generált szintaxis — backtick-kel idézett azonosítók, egyszeres idézőjeles szövegértékek, szabványos INSERT INTO ... VALUES ... — gyakori a MySQL, PostgreSQL és SQLite között. A PostgreSQL szigorúan nem igényel backtick-eket az azonosítók körül (dupla idézőjelet használ, ha egyáltalán kell idézés), de a backtick-kel idézett nevek ott is ártalmatlanok, amíg nincsenek szokatlan oszlopnevek, amelyek ütköznek fenntartott szavakkal. Nincs egyetlen hivatalos SQL szabvány, amelyet itt követnénk — csak az a szintaxis, amely módosítás nélkül működik a legelterjedtebb adatbázisokban.

Miért lesz egy üres cellából NULL, nem pedig üres string ''?

Ez egy tudatos tervezési döntés: a legtöbb valós CSV exportban egy üres cella azt jelenti, hogy az érték ismeretlen vagy nem alkalmazható, nem szó szerint egy üres szövegdarabot. A legtöbb adatbázis-séma ezt várja el. Ha az esetedben valóban üres stringre van szükséged, ezekben az esetekben kézzel kell szerkesztened a generált SQL-t.

Hogyan dönti el az eszköz, hogy egy értéknek idézőjelre van-e szüksége?

Ez egy egyszerű heurisztika, nem valódi típuskövetkeztetés: ha egy levágott cella csak számjegyekből áll (opcionálisan egy vezető mínuszjellel és legfeljebb egy tizedesponttal), számként, idézőjel nélkül íródik. Minden más szövegként kerül idézőjelbe. Ez azt jelenti, hogy egy 00501-hez hasonló irányítószám vagy egy telefonszám szövegként kezelendő (mivel a szigorú egész szám mintát csak akkor bukja el, ha extra karakterei vannak — egy önmagában lévő vezető nulla itt továbbra is számként elemződik, ezért ellenőrizd az olyan azonosítókat, mint irányítószámok és ID-k, mielőtt futtatnád az SQL-t).

Feltöltésre kerül valahova az adatom?

Nem. Az elemzés és az SQL generálás is JavaScriptben, a böngésződben történik — semmi sem kerül elküldésre egy szerverre, ami biztonságossá teszi az exportált ügyfél- vagy üzleti adatokkal való használatra.

Kezeli olyan CSV értékeket, amelyek vesszőt vagy idézőjelet tartalmaznak?

Igen. A CSV egy megfelelő, idézett mezőket kezelő elemzővel van feldolgozva, amely érti a vesszőket, sortöréseket és a megduplázott idézőjeleket az idézett mezőkön belül — nem egy naiv, vesszőn alapuló felosztás —, így egy olyan mező, mint a "Smith, John", egyetlen értékként olvasódik, nem osztódik két oszlopra.

Kapcsolódó eszközök