SQL-Konvertierung (SQL Conversion) bezeichnet den Vorgang, Daten aus SQL-Skripten zu extrahieren und in andere Datenformate wie JSON, CSV, XML, YAML, HTML oder Markdown umzustrukturieren. SQL (Structured Query Language) ist die Standardabfragesprache relationaler Datenbanken. Datenbank-Exportwerkzeuge wie mysqldump oder pg_dump geben Daten häufig als INSERT-Anweisungen in SQL-Skripten aus. Dieses Format ist zwar bequem für Datenbank-Imports, aber unhandlich für Programme, Datenanalysen oder den systemübergreifenden Austausch und muss daher in allgemeinere Formate umgewandelt werden.
Typische SQL-Datenexport-Skripte enthalten zwei Arten von Anweisungen: CREATE TABLE definiert die Tabellenstruktur (Spaltennamen, Datentypen, Constraints), und INSERT INTO ... VALUES (...) fügt die eigentlichen Daten ein. Dieses Tool parst beide Anweisungstypen: Aus CREATE TABLE werden Spaltendefinitionen und Typinformationen extrahiert, aus INSERT die tatsächlichen Datenzeilen, und das Ergebnis wird im vom Benutzer gewählten Format ausgegeben. Der gesamte Parsing-Prozess erfolgt lokal im Browser ohne Backend-Dienste.
Warum ist es nötig, SQL in andere Formate umzuwandeln? SQL-Skripte sind zwar universell, aber in folgenden Szenarien unpraktisch: Erstens ist es für Frontend-Programme deutlich einfacher, JSON zu lesen, als SQL zu parsen, da kein SQL-Parser erforderlich ist. Zweitens unterstützen Tabellenkalkulationen wie Excel oder Google Sheets nativ CSV, nicht jedoch SQL. Drittens sind YAML und Markdown in Konfigurations- und Dokumentationsszenarien besser lesbar als SQL. Viertens wird beim systemübergreifenden Datenaustausch häufig XML oder JSON als neutrales Format verwendet. Nach der Umwandlung in diese allgemeinen Formate können die Daten direkt von mehr Werkzeugen und Sprachen verarbeitet werden.
Der SQL-Parser dieses Tools ist handgeschrieben und konzentriert sich auf INSERT- und CREATE TABLE-Anweisungen. Für INSERT werden sowohl Einzelwert-Tupel (INSERT INTO t (a,b) VALUES (1,2)) als auch mehrwertige Tupel (INSERT INTO t (a,b) VALUES (1,2), (3,4), (5,6)) unterstützt, wobei die Daten automatisch nach Spaltennamen zugeordnet werden. Für CREATE TABLE werden Spaltendefinitionen, Datentypen (z. B. VARCHAR(255), INT, DECIMAL(10,2) mit Klammern-Länge), Constraints und Klauseln wie NOT NULL, PRIMARY KEY und IF NOT EXISTS geparst. Verschachtelte Klammern werden korrekt behandelt, um fehlerhaftes Splitten zu vermeiden.
Die Typerkennung ist entscheidend für die SQL-Konvertierung. Das Tool ermittelt den Typ automatisch anhand der Literalform des Werts: Einfache oder doppelte Anführungszeichen kennzeichnen eine Zeichenkette, NULL (ohne Berücksichtigung der Groß-/Kleinschreibung) den Nullwert, TRUE/FALSE boolesche Werte, 0x..., X'...', B'...' Hexadezimalliterale und reine Zahlen (mit Vorzeichen, Dezimalpunkt, wissenschaftlicher Notation) den Typ Zahl. Diese automatische Typerkennung stellt sicher, dass JSON, CSV und andere Formate die Semantik der Originaldaten beibehalten (z. B. die Zahl 1 und nicht die Zeichenkette "1"), damit nachgelagerte Programme korrekt arbeiten können.
Die unterschiedlichen Bezeichner-Anführungszeichen der Datenbankdialekte sind eine häufige Stolperfalle beim SQL-Parsing. MySQL verwendet standardmäßig Backticks (`) für Bezeichner (Tabellen- und Spaltennamen), PostgreSQL doppelte Anführungszeichen ("), SQL Server/T-SQL eckige Klammern ([]), und Standard-SQL gleichfalls doppelte Anführungszeichen. Die Funktion unquoteIdentifier dieses Tools erkennt diese Anführungszeichen automatisch und entfernt sie, einschließlich der Behandlung von Escapes innerhalb der Anführungszeichen (z. B. `` → `, "" → "). Im SQL-Rekonstruktionsmodus kann INSERT mit der Anführungszeichen-Schreibweise des gewählten Zieldialekts neu generiert werden.
Das SQL-Zeichenketten-Escaping ist ein weiterer zentraler technischer Punkt. Der SQL-Standard schreibt vor, dass einfache Anführungszeichen innerhalb von Zeichenketten durch Verdopplung escapet werden ('It''s' steht für It's). MySQL unterstützt zusätzlich Backslash-Escapes (\n, \t, \', \", \\, \0, \Z). Der Zeichenketten-Parser dieses Tools behandelt beide Escape-Mechanismen und stellt die ursprüngliche Zeichenkette korrekt wieder her. Bei der Umwandlung in CSV werden Felder mit Komma, Anführungszeichen oder Zeilenumbruch gemäß RFC 4180 erneut escapet. Bei der Umwandlung in XML/HTML werden Sonderzeichen wie &, <, >, ", ' escapet.
Die rein browserbasierte Verarbeitung ist ein zentrales Designprinzip dieses Tools. Alle SQL-Parsing- und Datenkonvertierungsschritte werden in der JavaScript-Engine des Browsers ausgeführt, ohne Daten an einen Server zu senden. Das bedeutet: Selbst wenn das SQL-Skript personenbezogene, geschäftssensible oder interne Datenbankstrukturen enthält, gelangen diese nicht nach außen. Diese Auslegung ist besonders geeignet für Exporte aus Produktionsdatenbanken, da Daten-Compliance-Bedenken entfallen. Gleichzeitig gibt es bei Frontend-Verarbeitung keine Netzwerklatenz; die Konvertierungsgeschwindigkeit wird nur durch CPU und Speicher des Geräts begrenzt.
Im Vergleich zu traditionellen Kommandozeilen-Tools für die SQL-Konvertierung (wie sql2csv oder sqlparser) bietet dieses Tool mehrere Vorteile: keine Installation und keine Umgebungskonfiguration, sondern direkte Nutzung über die Webseite; visuelle Oberfläche mit Echtzeit-Vorschau der Ergebnisse; Wechsel zwischen mehreren Ausgabeformaten mit einem Klick; integrierte Beispieldaten und Hilfedokumentation; responsives Mobile-Design für den Einsatz von überall. Dafür konzentriert sich dieses Tool auf die Datenextraktion und behandelt keine komplexen Dialektunterschiede (wie PostgreSQL-JSONB-Operatoren oder MySQL ON DUPLICATE KEY UPDATE) oder erweiterte Funktionen (Stored Procedures, Functions, Trigger). Für solche Anforderungen sollten native Datenbankwerkzeuge oder spezielle ETL-Plattformen verwendet werden.
Bei der Nutzung des SQL-Konvertierungstools sind einige Best Practices zu beachten: Erstens vor der Konvertierung prüfen, ob das SQL-Skript vollständige Daten (INSERT-Anweisungen) und nicht nur Abfragen (SELECT) enthält, da SELECT nicht geparst wird. Zweitens bei SQL-Skripten mit mehreren Tabellen „Mehrere Tabellen separat ausgeben“ aktivieren, um Tabellenstruktur-Informationen zu erhalten. Drittens bei SQL mit chinesischen Zeichen in der CSV-Ausgabe „BOM einbinden“ aktivieren, damit Excel die Kodierung korrekt erkennt. Viertens bei großen SQL-Dumps „hübsche Ausgabe“ deaktivieren, um das Ausgabevolumen zu reduzieren. Fünftens beim datenbankübergreifenden Migrieren den Modus „SQL-Rekonstruktion“ verwenden, um den Dialekt zu wechseln; komplexe Typen (wie PostgreSQL-Arrays, JSONB) können jedoch manuelle Anpassungen erfordern.
