CodeKitHub
JSON-tools

CSV naar SQL Converter

Laatst bijgewerkt:

Om een CSV-rij om te zetten naar SQL wordt elke kolom een waarde in een INSERT INTO-statement — getallen blijven zonder aanhalingstekens, tekst wordt tussen enkele aanhalingstekens gezet met interne aanhalingstekens verdubbeld (O'Brien wordt O''Brien), en lege cellen worden NULL. Deze tool past die omzetting toe op je volledige CSV-bestand, volledig in je browser.

Wat is deze tool?

Een testdatabase vullen, een spreadsheet-export in een tabel laden, of een klein dataset migreren begint vaak op dezelfde manier: je hebt een CSV-bestand en je hebt SQL nodig. Deze tool parst je CSV (met de header-rij als kolomnamen) en bouwt één INSERT INTO-statement dat elke datarij dekt, klaar om te plakken in een databaseclient.

Tekstwaarden worden tussen enkele aanhalingstekens gezet met interne aanhalingstekens verdubbeld (zo wordt O'Brien O''Brien), de standaard escaperegel die MySQL, PostgreSQL en SQLite delen. Een lege CSV-cel wordt geschreven als het SQL-sleutelwoord NULL in plaats van een lege string — dat is een bewuste keuze, aangezien een lege cel in een spreadsheet meestal 'geen waarde' betekent in plaats van 'een leeg stukje tekst', en NULL is wat de meeste schema's daarvoor verwachten.

Of een waarde tussen aanhalingstekens komt of niet, wordt bepaald door een eenvoudige heuristiek, geen echte typeherkenning: als de bijgesneden cel eruitziet als een gewoon geheel getal of decimaal getal (eventueel met een minteken vooraan), wordt het zonder aanhalingstekens geschreven; al het andere — inclusief dingen die alleen lijken op getallen met extra tekens, zoals telefoonnummers of postcodes met voorloopnullen — wordt als tekst tussen aanhalingstekens gezet. Dit houdt de output eerlijk: het is een goed startpunt voor een kleine import, geen vervanging voor het valideren van je data tegen je daadwerkelijke tabelschema voordat je het uitvoert.

Bron: CSV-parsing volgt RFC 4180, het dichtste bij een formele CSV-standaard; het verdubbelen van enkele aanhalingstekens voor tekst-escaping is de gedeelde conventie zoals gedocumenteerd door MySQL, PostgreSQL en SQLite.

Waarom gebruiken?

  • Aangepaste tabelnaam — stel de doeltabel eenmaal in, en elke rij richt zich op die tabel.
  • Correcte tekst-escaping — enkele aanhalingstekens binnen waarden worden verdubbeld zodat de SQL niet breekt of wordt afgekapt.
  • Voorspelbare NULL-afhandeling — lege cellen worden NULL in plaats van een lege string, overeenkomstig hoe de meeste databases ontbrekende data onderscheiden.
  • Gangbare SQL-syntax — de hier gegenereerde INSERT INTO ... VALUES ...-vorm werkt ongewijzigd in MySQL, PostgreSQL en SQLite.
  • 100% client-side — je CSV-data (die klantgegevens of bedrijfsdata kan bevatten) wordt in je browser geparst en omgezet en nooit ergens geüpload.

Hoe te gebruiken

  1. Plak CSV-data met een header-rij, bijv. name,age\nAlice,30\nBob,25.
  2. Voer de doeltabelnaam in (standaard my_table).
  3. Klik op "Generate SQL".
  4. Kopieer het INSERT INTO-statement of download het als .sql-bestand, en voer het daarna uit tegen je database.

Voorbeeld

Invoer

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

Uitvoer

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

Let op: de lege cellen werden NULL (geen lege strings), en de getalachtige leeftijdswaarde 30 bleef zonder aanhalingstekens terwijl elke tekstwaarde tussen aanhalingstekens kwam.

Praktische tips

  • Een lokale testdatabase vullen: exporteer een klein voorbeeld als CSV vanuit een spreadsheet, zet het hier om, en voer het INSERT-statement uit tegen je dev-database.
  • Controleer altijd de kolomtypes voordat je de gegenereerde SQL tegen een echte tabel uitvoert — deze tool leidt numeriek versus tekst af met een eenvoudige heuristiek, niet je daadwerkelijke schema, dus een integer-kolom die een specifiek formaat verwacht kan handmatige aanpassing nodig hebben.
  • Bij duizenden rijen is het enkele multi-rij INSERT-statement dat deze tool genereert nog steeds geldige SQL, maar zeer grote statements kunnen de maximale packet-grootte van een database raken — splits de CSV eerst op in kleinere batches als je die limiet tegenkomt.

Waarom NULL en geen lege string

Een veelgemaakte fout bij het handmatig schrijven van CSV-naar-SQL-scripts is elke ontbrekende cel behandelen als een lege string ''. Dat is technisch geldige SQL, maar meestal betekent het niet wat je wilt: een kolom gedefinieerd als integer weigert '' rechtstreeks, en zelfs in een tekstkolom betekent '' stilzwijgend iets anders dan "we kennen deze waarde niet" in de meeste schema-ontwerpen en rapportagequery's (een WHERE column IS NULL-check matcht geen lege strings, en omgekeerd). NULL gebruiken voor lege cellen sluit aan bij de semantiek die de meeste databases en ORM's verwachten, en voorkomt typefouten wanneer een numerieke kolom toevallig ontbrekende waarden heeft in sommige rijen.

Veelgestelde vragen

Werkt dit met elke SQL-database?

De gegenereerde syntax — identifiers tussen backticks, tekstwaarden tussen enkele aanhalingstekens, standaard INSERT INTO ... VALUES ... — is gangbaar in MySQL, PostgreSQL en SQLite. PostgreSQL vereist backticks rond identifiers strikt genomen niet (het gebruikt dubbele aanhalingstekens als überhaupt aanhalingstekens nodig zijn), maar identifiers tussen backticks zijn daar ook onschadelijk zolang je geen ongebruikelijke kolomnamen hebt die botsen met gereserveerde woorden. Er wordt geen enkele officiële SQL-standaard gevolgd — alleen de syntax die ongewijzigd werkt over de meest gangbare databases.

Waarom wordt een lege cel NULL in plaats van een lege string ''?

Dit is een bewuste ontwerpkeuze: bij de meeste echte CSV-exports betekent een lege cel dat de waarde onbekend of niet van toepassing is, niet letterlijk een leeg stukje tekst. NULL is wat de meeste databaseschema's daarvoor verwachten. Als jouw use case echt lege strings nodig heeft, moet je de gegenereerde SQL voor die gevallen handmatig aanpassen.

Hoe bepaalt de tool of een waarde aanhalingstekens nodig heeft?

Het is een eenvoudige heuristiek, geen echte typeherkenning: als een bijgesneden cel alleen uit cijfers bestaat (met een optioneel minteken vooraan en hooguit één decimaalpunt), wordt het zonder aanhalingstekens als getal geschreven. Al het andere wordt als tekst tussen aanhalingstekens gezet. Dit betekent dat een postcode zoals 00501 of een telefoonnummer als tekst wordt behandeld (aangezien het alleen faalt op het strikte gehele-getal-patroon bij extra tekens — een voorloopnul alleen parst hier nog steeds als numeriek, dus controleer identifiers zoals postcodes en id's dubbel voordat je de SQL uitvoert).

Wordt mijn data ergens geüpload?

Nee. Zowel het parsen als het genereren van SQL gebeurt in JavaScript in je browser — er wordt niets naar een server gestuurd, wat dit veilig maakt om te gebruiken met geëxporteerde klant- of bedrijfsgegevens.

Kan het CSV-waarden aan die komma's of aanhalingstekens bevatten?

Ja. De CSV wordt geparst met een echte parser voor velden tussen aanhalingstekens die komma's, regeleinden en verdubbelde aanhalingstekens binnen velden begrijpt — geen naïeve split op komma's — dus een veld zoals "Smith, John" wordt gelezen als één waarde, niet gesplitst in twee kolommen.

Gerelateerde tools