Hören Sie auf, INSERT-Anweisungen von Hand zu schreiben: JSON-zu-SQL-Konverter nutzen

Sie haben 200 Zeilen Benutzerdaten von einem Drittanbieter exportiert. Das Format ist JSON. Ihre Datenbank benötigt SQL-INSERT-Anweisungen. Und aus irgendeinem Grund denken Sie daran, sie von Hand zu schreiben.

Dieser Gedankengang geht ungefähr so: JSON-Datei öffnen, die Struktur betrachten, die CREATE TABLE-Anweisung schreiben, dann mit den INSERT-Anweisungen beginnen. Die erste dauert zwei Minuten. Die zweite eine Minute. Beim zehnten haben Sie eine Art Routine. Beim fünfzigsten haben Sie einen Tippfehler eingebaut, den Sie erst bemerken, wenn der Import mit einem Constraint-Fehler fehlschlägt.

Es gibt einen besseren Weg. Der JSON-zu-SQL-Konverter nimmt Ihr JSON-Array, leitet das Schema ab und produziert ausführbereites SQL — INSERT-Anweisungen in Bulk mit den richtigen Spaltennamen und zitierten Werten. Dieser Leitfaden erklärt, was das Tool tut, wie man es effektiv nutzt und wo Sie noch manuelle Bereinigung benötigen werden.

Was das Tool tatsächlich tut

Kurz gesagt: Sie fügen ein JSON-Array von Objekten ein, wählen einen SQL-Dialekt, und das Tool generiert zwei Dinge — eine CREATE TABLE-Anweisung basierend auf dem abgeleiteten Schema und eine Reihe von INSERT-Anweisungen für Ihre Daten.

Die Typableitung ist der interessante Teil. Das Tool betrachtet die Werte in Ihrem JSON und macht vernünftige Schätzungen über SQL-Typen. Zeichenketten werden zu VARCHAR oder TEXT. Zahlen werden zu INT oder FLOAT. Booleans werden abhängig von Ihrem Dialekt zu BOOLEAN oder TINYINT(1). Null-Werte werden standardmäßig zu nullbarem VARCHAR.

Es behandelt auch die Formatierungsunterschiede zwischen SQL-Dialekten automatisch — Backtick-zitierte Spaltennamen für MySQL, doppelt zitierte Bezeichner für PostgreSQL, NVARCHAR für SQL-Server-Textspalten.

Ein realistisches Beispiel

Angenommen, Sie haben einen JSON-Export einer SaaS-App. Der Users-Tabellen-Export sieht so aus:

[
  {
    "id": 1,
    "name": "Alice Chen",
    "email": "alice@example.com",
    "age": 31,
    "active": true,
    "created_at": "2025-01-15T09:23:00Z"
  },
  {
    "id": 2,
    "name": "Ben Kowalski",
    "email": "ben@example.com",
    "age": 28,
    "active": false,
    "created_at": "2025-02-03T14:55:00Z"
  },
  {
    "id": 3,
    "name": "Sara Okonkwo",
    "email": "sara@example.com",
    "age": 34,
    "active": true,
    "created_at": "2025-03-11T08:00:00Z"
  }
]

Das einfügen, MySQL wählen, und die Ausgabe sieht so aus:

CREATE TABLE `users` (
  `id` INT,
  `name` VARCHAR(255),
  `email` VARCHAR(255),
  `age` INT,
  `active` BOOLEAN,
  `created_at` VARCHAR(255)
);

INSERT INTO `users` (`id`, `name`, `email`, `age`, `active`, `created_at`) VALUES
(1, 'Alice Chen', 'alice@example.com', 31, TRUE, '2025-01-15T09:23:00Z'),
(2, 'Ben Kowalski', 'ben@example.com', 28, FALSE, '2025-02-03T14:55:00Z'),
(3, 'Sara Okonkwo', 'sara@example.com', 34, TRUE, '2025-03-11T08:00:00Z');

Bei 200 Zeilen bekämen Sie dieselbe Struktur, aber mit einem Batch von 200 Werten. Das ist die Ausgabe von vielleicht dreißig Sekunden Einfügen und Klicken, gegenüber fünfzehn Minuten fehleranfälligem Tippen.

Beachten Sie ein paar Dinge in dieser Ausgabe. Das Feld created_at ist als VARCHAR(255) statt DATETIME typisiert — warum das wichtig ist, erklären wir gleich. Der Tabellenname ist standardmäßig users; das Tool lässt Sie ihn möglicherweise angeben. Das CREATE TABLE enthält keine PRIMARY KEY- oder NOT NULL-Constraints — das ist Ihre Aufgabe.

Dialektunterschiede, die es wert sind, bekannt zu sein

Der "SQL-Dialekt"-Selektor ist wichtiger als er vielleicht erscheint. Syntaxunterschiede zwischen Datenbanken sind klein, aber sie verursachen Fehler, wenn Sie den falschen wählen.

MySQL verwendet Backticks zum Zitieren von Bezeichnern: `column_name`. Das ist wichtig, wenn Ihr Spaltenname zufällig mit einem reservierten MySQL-Wort kollidiert (wie order, key, index oder values). MySQL verwendet in älteren Schemas auch TINYINT(1) für Booleans, obwohl BOOLEAN in MySQL 5.7+ funktioniert.

PostgreSQL verwendet doppelte Anführungszeichen für Bezeichner: "column_name". Es hat native BOOLEAN- und TIMESTAMP WITH TIME ZONE-Typen. Es hat auch SERIAL und BIGSERIAL für automatisch inkrementierende Primärschlüssel, was sich von MySQLs AUTO_INCREMENT unterscheidet.

SQLite ist permissiv bei Typen — SQLite verwendet "Typaffinität" statt strenger Typen, sodass eine als TEXT deklarierte Spalte Ganzzahlen speichern kann und umgekehrt. Bei SQLite-Ausgaben sehen Sie oft einfachere Typnamen wie TEXT und INTEGER.

SQL Server verwendet NVARCHAR statt VARCHAR für Unicode-Textzeichenketten und eckige Klammern zum Zitieren von Bezeichnern: [column_name]. SQL Server verwendet auch BIT für Boolean-Werte statt BOOLEAN oder TINYINT.

Wenn Sie in eine bestimmte Datenbank importieren, wählen Sie diesen Dialekt. Wenn Sie das SQL manuell ausführen und anpassen werden, gibt Ihnen jeder Dialekt einen verwendbaren Ausgangspunkt — achten Sie nur darauf, was Sie ändern müssen.

Typableitung: Was funktioniert und wo sie versagt

Das Tool ist bei gängigen Fällen ziemlich gut:

• 123 in JSON wird zu INT in SQL
• 123.45 wird zu FLOAT oder DECIMAL
• "hello" wird zu VARCHAR(255) oder TEXT
• true / false wird zu BOOLEAN oder TINYINT(1)
• null wird zu einer nullbaren Spalte, typischerweise als VARCHAR typisiert

Wo es versagt, ist überall dort, wo JSON Zeichenketten verwendet, um Nicht-Zeichenkettendaten darzustellen.

Telefonnummern sind eine klassische Falle. Wenn Ihr JSON "phone": "12345" hat, ist das eine Zeichenkette in JSON, und Sie bekommen VARCHAR(255) — was korrekt ist, da Telefonnummern als Zeichenketten gespeichert werden sollten (führende Nullen, Ländercodes mit +, formatierte Nummern). Wenn aber jemand Telefonnummern als nackte Ganzzahlen im Quellsystem gespeichert hat, sehen Sie möglicherweise "phone": 12345 und bekommen INT. Dann würde Ihr Import führende Nullen und Formatierung stillschweigend verwerfen.

Datums- und Zeitfelder kommen fast immer als VARCHAR heraus, weil JSON keinen nativen Datumstyp hat. "2025-01-15T09:23:00Z" ist für JSON nur eine Zeichenkette. Wenn Sie eine richtige DATETIME- oder TIMESTAMP-Spalte benötigen, ändern Sie den Spaltentyp in der CREATE TABLE-Anweisung nach der Generierung. Die Daten selbst werden beim Einfügen in eine TIMESTAMP-Spalte korrekt importiert, da SQL die ISO-8601-Zeichenkette parst.

IDs, die wie Zahlen aussehen, sind kniffliger. Ein id-Feld mit dem Wert 1042 wird als INT typisiert. Das könnte in Ordnung sein — oder Ihr System verwendet UUIDs oder alphanumerische IDs, die in den ersten paar Zeilen Ihres Musters zufällig alle numerisch sind. Wenn Zeile 201 id: "a1b2c3" hat, wird Ihr Import fehlschlagen.

Große Textfelder werden als VARCHAR(255) typisiert. Wenn ein Feld längere Inhalte enthält — Artikelkörper, Beschreibungen, serialisierte Daten — müssen Sie den Typ in MySQL zu TEXT oder LONGTEXT oder in PostgreSQL zu TEXT (ohne Längenbegrenzung) ändern.

Faustregel: Überprüfen Sie immer die generierte CREATE TABLE-Anweisung, bevor Sie sie ausführen. Die INSERT-Anweisungen sind normalerweise in Ordnung, aber die Schema-Ableitung ist der Punkt, wo menschliches Urteil gefragt ist.

Batch-Inserts: Warum sie wichtig sind

Bei kleinen Datensätzen — zehn oder zwanzig Zeilen — spielt es kaum eine Rolle, ob Sie eine Zeile nach der anderen oder in Batches einfügen. Bei größeren Datensätzen ist der Unterschied erheblich.

Ein Einzel-Zeilen-INSERT sieht so aus:

INSERT INTO `users` (`id`, `name`, `email`) VALUES (1, 'Alice', 'alice@example.com');
INSERT INTO `users` (`id`, `name`, `email`) VALUES (2, 'Ben', 'ben@example.com');
-- ... 198 weitere Anweisungen

Ein Batch-INSERT sieht so aus:

INSERT INTO `users` (`id`, `name`, `email`) VALUES
(1, 'Alice', 'alice@example.com'),
(2, 'Ben', 'ben@example.com'),
(3, 'Sara', 'sara@example.com'),
-- ... bis zu 100 Zeilen
;

INSERT INTO `users` (`id`, `name`, `email`) VALUES
(101, 'David', 'david@example.com'),
-- ... nächster Batch
;

Die Batch-Version ist aus zwei Gründen schneller. Erstens gibt es einen Netzwerk-Roundtrip pro Batch statt einen pro Zeile. Zweitens kann die Datenbank einen einzelnen großen Schreibvorgang besser optimieren als viele kleine — Transaktions-Overhead, Index-Updates und Write-Ahead-Logging finden einmal pro Anweisung statt, nicht einmal pro Zeile.

Der Grund, warum Konverter Batches typischerweise auf 100-500 Zeilen begrenzen, statt alles in eine Anweisung zu packen, ist Speicher und Zuverlässigkeit. Eine 10.000-Zeilen-Einzel-INSERT-Anweisung kann Speichergrenzen erreichen, langsam zu parsen sein, und wenn sie auf halbem Weg fehlschlägt, erhalten Sie kein nützliches Feedback darüber, welche Zeilen das Problem waren. Kleinere Batches sind praktischer.

Was das Tool nicht kann

Klarheit über Einschränkungen bewahrt Sie später vor einer Debugging-Sitzung.

Keine Fremdschlüssel. Der Konverter weiß nichts über Beziehungen zwischen Tabellen. Wenn Ihr JSON ein user_id-Feld hat, das auf eine andere Tabelle verweist, erhalten Sie eine einfache INT-Spalte — kein FOREIGN KEY-Constraint, keine REFERENCES-Klausel. Diese müssen Sie manuell hinzufügen.

Keine Indizes. Das generierte CREATE TABLE hat keine Indexdefinitionen. Wenn Sie einen großen Datensatz importieren und dann abfragen möchten, müssen Sie INDEX- oder UNIQUE INDEX-Definitionen auf Spalten hinzufügen, die Sie filtern oder joinen werden. Das ist immer ein Post-Import-Schritt.

Keine Primärschlüssel-Markierung. Das Tool erstellt möglicherweise eine id INT-Spalte, fügt aber kein PRIMARY KEY oder AUTO_INCREMENT hinzu. Wenn id ein richtiger automatisch inkrementierender Primärschlüssel sein soll, fügen Sie in MySQL PRIMARY KEY AUTO_INCREMENT zur Spaltendefinition hinzu oder wechseln Sie in PostgreSQL zu SERIAL.

Keine komplexen oder verschachtelten Typen. Wenn ein Feldwert ein Objekt oder Array ist, kann das Tool das nicht in ein relationales Schema abflachen. Es serialisiert es typischerweise als JSON-Zeichenkette oder überspringt das Feld. Sie müssen entscheiden: Als JSON-Spalte speichern (MySQL 5.7+ und PostgreSQL unterstützen native JSON-Spalten), in separate Spalten abflachen oder in eine separate Tabelle normalisieren.

Keine Upsert-Logik. Die generierten Anweisungen sind einfache INSERT ohne Konfliktbehandlung. Wenn Sie sie gegen eine Tabelle ausführen, die bereits Daten mit überlappenden Primärschlüsseln enthält, erhalten Sie Constraint-Verletzungsfehler. Für idempotente Imports benötigen Sie INSERT IGNORE in MySQL, ON CONFLICT DO NOTHING in PostgreSQL oder MERGE in SQL Server — nichts davon fügt das Tool automatisch hinzu.

Keine Transaktionen. Die Ausgabe ist nicht in BEGIN TRANSACTION / COMMIT eingeschlossen. Bei großen Imports ist es gute Praxis, alles in eine Transaktion einzuschließen — wenn etwas auf halbem Weg fehlschlägt, können Sie sauber rollbacken. Fügen Sie es selbst um die generierten Anweisungen herum hinzu.

Wann dieses Tool statt anderer Optionen verwenden

Der JSON-zu-SQL-Konverter ist das richtige Tool für bestimmte Situationen. Er ist nicht das richtige Tool für alles.

Verwenden Sie es wenn:

• Sie einen einmaligen Datenimport von einer externen Quelle haben
• Sie Daten zwischen Datenbanken migrieren und einen schnellen SQL-Dump benötigen
• Sie eine Demo- oder Testdatenbank mit realistisch aussehenden Daten einrichten
• Sie direkt mit SQL arbeiten und keinen Anwendungs-Stack laufen haben
• Sie Daten mit jemandem teilen müssen, der nur SQL-Zugang hat

Greifen Sie stattdessen zu Ihrem ORM oder ETL-Tool wenn:

• Sie wiederholbare, versionskontrollierte Seed-Daten benötigen — Tools wie Prismas db seed, Djangos fixtures oder Rails' Seed-Dateien integrieren sich in Ihren Migrations-Workflow und können sicher wiederausgeführt werden
• Der Import komplex ist und Datentransformation beinhaltet, nicht nur das Einfügen
• Sie Beziehungen und Fremdschlüssel-Constraints programmatisch behandeln müssen
• Sie das regelmäßig nach einem Zeitplan tun — schreiben Sie ein richtiges ETL-Skript oder verwenden Sie ein Tool wie Apache NiFi, dbt oder sogar ein einfaches Python-Skript mit pandas und sqlalchemy

Der JSON-zu-SQL-Konverter ist im Wesentlichen eine Abkürzung für das Szenario "Ich muss diese Daten nur in eine Tabelle bekommen". Wenn das Szenario komplexer als das ist, benötigen Sie ein komplexeres Tool.

Ein praktischer Workflow

Hier ist die Abfolge, die gut funktioniert:

1. Formatieren Sie zuerst Ihr JSON. Wenn Ihr Export minifiziert ist, fügen Sie ihn zuerst durch den JSON-Formatter ein. So können Sie die Struktur überprüfen und eventuelle Probleme vor der Konvertierung erkennen.

2. Überprüfen Sie die Array-Struktur. Der Konverter erwartet ein JSON-Array von Objekten, bei dem jedes Objekt dieselben Schlüssel auf der obersten Ebene hat. Wenn Ihr Export in einem Wurzelobjekt ({"data": [...]}) statt als nacktes Array verpackt ist, extrahieren Sie zuerst das Array.

3. Wählen Sie Ihren Dialekt und fügen Sie das JSON ein. Kopieren Sie das generierte SQL.

4. Überprüfen Sie das CREATE TABLE. Bevor Sie irgendetwas ausführen, lesen Sie die Spaltentypen durch und korrigieren Sie alles, was falsch aussieht — insbesondere Datumsfelder, große Textfelder und numerische Felder, die eigentlich Zeichenketten sein sollten.

5. Fügen Sie benötigte Constraints hinzu. Markieren Sie den Primärschlüssel, fügen Sie NOT NULL wo angemessen hinzu, fügen Sie UNIQUE bei E-Mail-Spalten hinzu und fügen Sie eventuelle FOREIGN KEY-Constraints hinzu.

6. Führen Sie zuerst CREATE TABLE aus, dann die INSERTs. Wenn die Tabelle bereits existiert und Sie reimportieren, entscheiden Sie, ob Sie zuerst DROP TABLE IF EXISTS ausführen oder eine Konfliktlösungsstrategie verwenden möchten.

7. Überprüfen Sie die Zeilenanzahl. Führen Sie nach dem Import SELECT COUNT(*) FROM your_table; aus und vergleichen Sie es mit der Anzahl der Zeilen in Ihrem JSON. Wenn sie übereinstimmen, sind Sie fertig.

Das Ausgabe-SQL formatieren

Das generierte SQL ist normalerweise lesbar, entspricht aber nicht immer Ihren Standards. Wenn Sie die INSERT-Anweisungen konsistent formatieren möchten — ausgerichtete Spalten, konsistente Groß-/Kleinschreibung für Schlüsselwörter — führen Sie die Ausgabe durch den SQL-Formatter. Das ändert die Semantik nicht, macht das SQL aber leichter zu überprüfen und zu vergleichen.

Zusammenfassung

INSERT-Anweisungen für große JSON-Datensätze von Hand zu schreiben ist eine jener Aufgaben, bei denen Automatisierung am meisten Sinn ergibt. Der JSON-zu-SQL-Konverter übernimmt die mechanische Konvertierung: Er liest Ihr Array, leitet Typen ab, generiert ein Schema und produziert Batch-INSERT-Anweisungen in Ihrem Zieldialekt.

Die Teile, die noch Ihre Aufmerksamkeit erfordern, sind Schema-Überprüfung (Typen, Constraints, Indizes), Behandlung verschachtelter Daten und Idempotent-Machen der INSERT-Logik, wenn Sie sie wiederholt ausführen müssen. Das Tool erledigt die 90%, die rein mechanisch sind. Die verbleibenden 10% sind Datenbankdesign-Urteilsvermögen, das keine Automatisierung ersetzen kann.

Wenn Sie regelmäßig mit JSON-Daten arbeiten, sind zwei weitere Tools wert, neben diesem mit einem Lesezeichen versehen zu werden: der JSON-Formatter zum Überprüfen und Bereinigen Ihrer Eingabe und der SQL-Formatter zum Aufräumen der generierten Ausgabe, bevor Sie sie in eine Migrations-Datei einpflegen.