CodeKitHub
JSON įrankiai

CSV į SQL konverteris

Paskutinį kartą atnaujinta:

Norint paversti CSV eilutę į SQL, kiekvienas stulpelis tampa reikšme INSERT INTO sakinyje — skaičiai lieka be kabučių, tekstas apgaubiamas viengubomis kabutėmis, o viduje esančios kabutės padvigubinamos (O'Brien tampa O''Brien), o tuščios ląstelės tampa NULL. Šis įrankis pritaiko šį konvertavimą visam jūsų CSV failui, viskas vyksta jūsų naršyklėje.

Kas yra šis įrankis?

Testinės duomenų bazės užpildymas pavyzdiniais duomenimis, skaičiuoklės eksporto įkėlimas į lentelę ar mažo duomenų rinkinio migravimas dažniausiai prasideda taip pat: turite CSV failą ir jums reikia SQL. Šis įrankis analizuoja jūsų CSV (naudodamas antraštės eilutę kaip stulpelių pavadinimus) ir sukuria vieną INSERT INTO sakinį, apimantį kiekvieną duomenų eilutę, paruoštą įklijuoti į duomenų bazės klientą.

Teksto reikšmės apgaubiamos viengubomis kabutėmis, o viduje esančios kabutės keičiamos padvigubinant jas (todėl O'Brien tampa O''Brien) — tai standartinė kabučių apdorojimo taisyklė, bendra MySQL, PostgreSQL ir SQLite. Tuščia CSV ląstelė rašoma kaip SQL raktažodis NULL, o ne kaip tuščia eilutė — tai sąmoningas pasirinkimas, nes tuščia ląstelė skaičiuoklėje dažniausiai reiškia „nėra reikšmės“, o ne „tuščias teksto fragmentas“, ir dauguma schemų tikisi būtent NULL.

Ar reikšmė apgaubiama kabutėmis, ar paliekama nuoga, nusprendžia paprasta heuristika, o ne tikras tipų nustatymas: jei apkarpyta ląstelė atrodo kaip paprastas sveikasis ar dešimtainis skaičius (galimai su minuso ženklu priekyje), ji rašoma be kabučių; visa kita — įskaitant dalykus, kurie tik panašūs į skaičius su papildomais simboliais, pvz., telefono numerius ar pašto kodus su nuliais priekyje — apgaubiama kabutėmis kaip tekstas. Tai išlaiko rezultatą sąžiningą: tai geras pradinis taškas nedideliam importui, bet ne pakaitalas savo duomenų patikrinimui pagal tikrąją lentelės schemą prieš paleidžiant.

Šaltinis: CSV analizavimas vykdomas pagal RFC 4180, artimiausią formaliam CSV standartui; viengubų kabučių padvigubinimas eilučių apsaugai yra bendra konvencija, dokumentuota MySQL, PostgreSQL ir SQLite.

Kodėl jį naudoti?

  • Pasirinktinis lentelės pavadinimas — nustatykite paskirties lentelę vieną kartą, ir kiekviena eilutė nukreipiama į tą lentelę.
  • Teisingas eilučių apsaugojimas — viengubos kabutės reikšmių viduje padvigubinamos, kad SQL nesugestų ar nebūtų nutrauktas.
  • Nuspėjamas NULL apdorojimas — tuščios ląstelės tampa NULL, o ne tuščia eilute, atitinkant tai, kaip dauguma duomenų bazių atskiria trūkstamus duomenis.
  • Įprasta SQL sintaksė — čia sugeneruota INSERT INTO ... VALUES ... forma veikia be pakeitimų MySQL, PostgreSQL ir SQLite.
  • 100% apdorojimas kliento pusėje — jūsų CSV duomenys (kurie gali apimti klientų įrašus ar verslo duomenis) analizuojami ir konvertuojami jūsų naršyklėje ir niekada niekur neįkeliami.

Kaip naudoti

  1. Įklijuokite CSV duomenis su antraštės eilute, pvz., name,age\nAlice,30\nBob,25.
  2. Įveskite paskirties lentelės pavadinimą (numatytoji reikšmė — my_table).
  3. Spustelėkite „Generuoti SQL“.
  4. Nukopijuokite INSERT INTO sakinį arba atsisiųskite jį kaip .sql failą, tada paleiskite jį savo duomenų bazėje.

Pavyzdys

Įvestis

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

Išvestis

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

Atkreipkite dėmesį, kad tuščios ląstelės tapo NULL (o ne tuščiomis eilutėmis), o skaičių primenanti amžiaus reikšmė 30 liko be kabučių, o kiekviena teksto reikšmė buvo apgaubta kabutėmis.

Praktiniai patarimai

  • Vietinės testinės duomenų bazės užpildymas: eksportuokite nedidelį pavyzdį kaip CSV iš skaičiuoklės, konvertuokite jį čia ir paleiskite INSERT sakinį savo kūrimo duomenų bazėje.
  • Visada peržiūrėkite stulpelių tipus prieš paleisdami sugeneruotą SQL prieš tikrą lentelę — šis įrankis nustato skaičius nuo teksto paprasta heuristika, o ne pagal jūsų tikrą schemą, todėl sveikojo skaičiaus stulpeliui, tikinčiam specifinio formato, gali prireikti rankinio koregavimo.
  • Jei turite tūkstančius eilučių, šio įrankio sugeneruotas vienas kelių eilučių INSERT sakinys vis tiek yra galiojantis SQL, bet labai dideli sakiniai gali viršyti duomenų bazės maksimalų paketo dydį — pirmiausia padalinkite CSV į mažesnes partijas, jei susiduriate su šiuo apribojimu.

Kodėl NULL, o ne tuščia eilutė

Dažna klaida rankiniu būdu rašant CSV-į-SQL scenarijus yra kiekvieną trūkstamą ląstelę traktuoti kaip tuščią eilutę ''. Tai techniškai galiojantis SQL, bet dažniausiai tai nereiškia to, ko norite: sveikojo skaičiaus tipu apibrėžtas stulpelis tiesiog atmes '', o net teksto stulpelyje '' tyliai reiškia kažką kitą nei „mes nežinome šios reikšmės“ daugumoje schemų dizainų ir ataskaitų užklausų (WHERE column IS NULL patikra neatitiks tuščių eilučių, ir atvirkščiai). NULL naudojimas tuščioms ląstelėms atitinka semantiką, kurios tikisi dauguma duomenų bazių ir ORM, ir tai padeda išvengti tipo klaidų, kai skaitiniame stulpelyje kai kuriose eilutėse pasitaiko trūkstamų reikšmių.

Dažniausiai užduodami klausimai

Ar tai veikia su kiekviena SQL duomenų baze?

Sugeneruota sintaksė — apstriža kabute apgaubti identifikatoriai, viengubomis kabutėmis apgaubtos teksto reikšmės, standartinis INSERT INTO ... VALUES ... — yra bendra MySQL, PostgreSQL ir SQLite. PostgreSQL griežtai nereikalauja apstrižų kabučių aplink identifikatorius (jis naudoja dvigubas kabutes, jei kabučių apskritai reikia), bet apstrižomis kabutėmis apgaubti pavadinimai ten taip pat nekenksmingi, jei neturite neįprastų stulpelių pavadinimų, sutampančių su rezervuotais žodžiais. Čia nesilaikoma jokio vieno oficialaus SQL standarto — tik sintaksė, kuri veikia be pakeitimų daugiausia paplitusiose duomenų bazėse.

Kodėl tuščia ląstelė tampa NULL, o ne tuščia eilute ''?

Tai sąmoningas dizaino sprendimas: daugumoje realių CSV eksportų tuščia ląstelė reiškia, kad reikšmė nežinoma arba netaikoma, o ne kad tai iš tikrųjų tuščias teksto fragmentas. Dauguma duomenų bazių schemų tikisi būtent NULL. Jei jūsų naudojimo atveju tikrai reikia tuščių eilučių, tokiais atvejais turėsite rankiniu būdu redaguoti sugeneruotą SQL.

Kaip įrankis nusprendžia, ar reikšmei reikia kabučių?

Tai paprasta heuristika, o ne tikras tipų nustatymas: jei apkarpyta ląstelė susideda tik iš skaitmenų (su galimu minuso ženklu priekyje ir daugiausiai vienu dešimtainiu tašku), ji rašoma be kabučių kaip skaičius. Visa kita apgaubiama kabutėmis kaip tekstas. Tai reiškia, kad pašto kodas, pvz., 00501, ar telefono numeris būtų laikomas tekstu (nes jis neatitinka griežto sveikojo skaičiaus šablono tik jei turi papildomų simbolių — vienas nulis priekyje vis tiek čia analizuojamas kaip skaičius, todėl prieš vykdydami SQL dukart patikrinkite tokius identifikatorius kaip pašto kodai ir ID).

Ar mano duomenys kur nors įkeliami?

Ne. Ir analizavimas, ir SQL generavimas vyksta JavaScript kalba jūsų naršyklėje — niekas nesiunčiama į serverį, todėl tai saugu naudoti su eksportuotais klientų ar verslo įrašais.

Ar jis apdoroja CSV reikšmes su kableliais ar kabutėmis?

Taip. CSV analizuojamas naudojant tinkamą kabutėse esančių laukų analizatorių, kuris supranta kablelius, eilučių lūžius ir padvigubintas kabutes kabutėse esančiuose laukuose — o ne primityvų skaidymą pagal kablelius — todėl toks laukas kaip "Smith, John" nuskaitomas kaip viena reikšmė, o ne suskaidomas į du stulpelius.

Susiję įrankiai