CSV in SQL umwandeln

Viele deutsche Kommunen und Behörden veröffentlichen ihre offenen Daten über Portale wie GovData.de ausschließlich als CSV — Haushaltsdaten, Standorte, Verzeichnisse. Wer diese Daten in eine eigene lokale Datenbank laden will, um sie mit SQL abzufragen, braucht dafür INSERT-Anweisungen, keine weitere Tabellenkalkulation.

Derselbe Bedarf entsteht bei einer Vereins- oder Mitgliederliste, die aus einem alten Programm nur als CSV exportierbar ist und in eine neue Datenbank umziehen soll. Diese Umwandlung übernimmt genau diesen einen Schritt: aus Zeilen und Spalten werden ausführbare SQL-Anweisungen.

Das Trennzeichen der CSV-Datei wird automatisch erkannt, sodass ein mit Semikolon getrenntes Excel-Exportformat ebenso funktioniert wie eines mit Komma. Die erste Zeile wird als Kopfzeile mit den Spaltennamen gelesen, jede folgende Zeile als ein Datensatz.

Zahlen und Wahrheitswerte werden dabei automatisch erkannt und nicht als Text behandelt — eine Spalte mit `42` wird als Zahl gelesen, nicht als die Zeichenkette „42". Das wirkt sich direkt darauf aus, wie der Wert später in der SQL-Datei geschrieben wird: eine Zahl ohne Anführungszeichen, Text mit.

Die fertige Datei enthält ausschließlich `INSERT INTO … VALUES …;`-Anweisungen, eine pro Zeile der ursprünglichen CSV-Datei. Es gibt keine `CREATE TABLE`-Anweisung und keine Angabe von Datentypen — die Zieltabelle muss vor dem Ausführen bereits existieren, mit Spalten, die zu den Werten passen.

Das ist eine bewusste Beschränkung und kein fehlendes Detail: Aus einer CSV-Datei allein lässt sich kein zuverlässiger Spaltentyp ableiten, weil eine Spalte mit lauter Ganzzahlen genauso gut als `INTEGER` wie als `VARCHAR` gemeint sein kann. Die Entscheidung bleibt bei der Person, die die Zieltabelle anlegt.

Ohne eine andere Angabe in der CSV-Datei wird der Tabellenname aus dem Dateinamen ohne Endung abgeleitet — `mitgliederliste.csv` wird zu `mitgliederliste`. Alles, was kein Buchstabe, keine Ziffer und kein Unterstrich ist, wird dabei durch einen Unterstrich ersetzt, und ein Name, der mit einer Ziffer beginnt, bekommt vorne einen Unterstrich angehängt, damit er ein gültiger SQL-Bezeichner bleibt.

Ein Dateiname wie `2024-vereinsdaten.csv` wird also zu `_2024_vereinsdaten` — technisch korrekt, aber nicht unbedingt der Name, den man von Hand gewählt hätte. Vor dem Ausführen lohnt sich deshalb ein kurzer Blick auf den erzeugten Tabellennamen.

Ein als Wahrheitswert erkannter Wert wird als `TRUE` oder `FALSE` geschrieben — die Schreibweise, die PostgreSQL, MySQL und die meisten modernen Systeme verstehen. Ältere oder strengere SQL-Dialekte kennen dieses Schlüsselwort teilweise nicht und erwarten stattdessen `1` und `0`.

Wer die erzeugte Datei in ein System einspielt, das mit `TRUE`/`FALSE` nichts anfangen kann, muss diese Werte vor dem Ausführen von Hand oder mit Suchen-und-Ersetzen anpassen — die Umwandlung selbst prüft den Zieldialekt nicht.

Die erzeugten Bezeichner für Tabelle und Spalten werden nicht in Anführungszeichen oder Backticks gesetzt. Das funktioniert, solange keine Spalte ein SQL-Schlüsselwort wie `order` oder `group` heißt oder ein Leerzeichen im Namen hat — beides wird durch die Bereinigung des Namens allerdings ohnehin meist schon in einen Unterstrich verwandelt.

Bei einer CSV-Datei mit sehr ungewöhnlichen Spaltennamen lohnt sich ein Blick auf die erste Zeile der erzeugten Datei, bevor sie gegen eine Datenbank ausgeführt wird.

SQL ist bei dieser Umwandlung ausschließlich ein Ziel, kein Ausgangspunkt: Es gibt kein Werkzeug auf dieser Seite, das INSERT-Anweisungen wieder in eine Tabelle zurückliest. Wer eine SQL-Datei in eine Tabellenform bringen will, braucht dafür eine Datenbank, die die Anweisungen ausführt, und einen anschließenden Export aus dieser Datenbank.

Das ist bei einer reinen Werteübertragung selten ein Problem — INSERT-Anweisungen sind für das Einspielen in eine Datenbank gedacht, nicht für die Weiterverarbeitung als Tabelle.

Jeder einzelne Wert aus der CSV-Datei landet unverändert in einer der INSERT-Anweisungen — in diesem engen Sinn geht bei der Umwandlung nichts verloren. Was dabei nicht mitkommt, ist alles, was eine CSV-Datei ohnehin nie enthält: Spaltentypen, Fremdschlüssel, Indizes oder Einschränkungen einer Datenbank.

Wer eine wirklich vollständige Tabellendefinition braucht, muss sie selbst anlegen. Diese Umwandlung liefert den Inhalt, nicht die Struktur der Zieldatenbank — und genau das steht auch so im Namen des Formats: eine INSERT-Anweisung fügt Werte in eine bereits bestehende Struktur ein.

Eine Mitgliederliste, eine Adressliste oder ein Datensatz mit Namen und Kontaktdaten fällt unter die DSGVO, sobald er auf einen fremden Server geladen wird. Diese Umwandlung läuft vollständig im Browser — die CSV-Datei wird an keiner Stelle irgendwohin verschickt, bevor die SQL-Datei entsteht.

Die freie Version verarbeitet Dateien bis 100 MB, was für die meisten Vereins- oder Behördentabellen weit ausreicht. Mehrere Dateien lassen sich gleichzeitig ablegen und werden nacheinander umgewandelt.

Vor dem Ausführen der erzeugten Datei braucht die Zieltabelle bereits eine `CREATE TABLE`-Anweisung mit passenden Spaltentypen — sonst schlägt jede einzelne INSERT-Anweisung fehl. Wer den Zieldialekt kennt, sollte außerdem prüfen, ob `TRUE`/`FALSE` dort verstanden wird und ob ein Spaltenname zufällig mit einem reservierten Wort kollidiert.

Für den eigentlichen Zweck — eine CSV-Tabelle schnell in eine Form zu bringen, die sich gegen eine bestehende Datenbank ausführen lässt — ist das trotzdem der schnellere Weg gegenüber einem manuellen Nachbau der Anweisungen von Hand.