Kostenloser SQL-zu-JSON-Konverter

Konvertieren Sie SQL-CREATE-TABLE-Anweisungen in JSON-Schema. Extrahieren Sie sofort Spaltennamen, Typen und Constraints.

Ihre Daten verlassen niemals Ihr Gerät

Über die SQL-zu-JSON-Konvertierung

Dieses Tool parst SQL-CREATE-TABLE-Anweisungen und konvertiert sie ins JSON-Schema-Format. Es extrahiert Spaltennamen, Datentypen (INT, VARCHAR, TEXT, BOOLEAN, DATE, TIMESTAMP, DECIMAL) und Constraints (NOT NULL, PRIMARY KEY, DEFAULT-Werte). Die JSON-Ausgabe eignet sich für API-Dokumentation, Datenbankdesign oder Migrationstools.

Unterstützte SQL-Datentypen

Häufig gestellte Fragen

Welche SQL-Dialekte werden unterstützt?

Dieser Konverter behandelt Standard-SQL-Syntax, die von MySQL, PostgreSQL, SQL Server und SQLite verwendet wird. Dialekt-spezifische Funktionen werden möglicherweise nicht vollständig erkannt.

Kann es komplexe Constraints behandeln?

Der Konverter erkennt NOT NULL, PRIMARY KEY, DEFAULT und grundlegende Typinformationen. Komplexe Constraints wie CHECK oder FOREIGN KEY werden als Text-Annotationen gespeichert.

Kann ich die JSON-Ausgabe direkt verwenden?

Ja! Die JSON-Ausgabe ist auf Lesbarkeit formatiert und kann in API-Schemata, TypeScript-Interfaces oder Dokumentations-Generatoren verwendet werden.

Schema, nicht Daten, was dieses Werkzeug tut

Dieser Konverter nimmt eine SQL-CREATE TABLE-Anweisung und gibt JSON Schema aus: eine Beschreibung der Spalten, Typen und grundlegenden Einschränkungen, geeignet für API-Verträge, die Generierung von TypeScript-Typen und Migrationen zu Dokumentspeichern. Es wandelt keine INSERT-Zeilen oder Abfrageergebnismengen in JSON um. Das Suchinteresse an „SQL zu JSON“ teilt sich etwa zur Hälfte zwischen diesen beiden Bedürfnissen auf; wenn Sie eine Zeilen-zu-Objekt-Umwandlung erwartet haben, brauchen Sie ein anderes Werkzeug. Der Schema-Umwandlungspfad ist der entwicklerorientierte Fall: Sie haben eine Tabellendefinition und möchten eine strukturierte Beschreibung ihrer Form, die ein anderes Werkzeug verarbeiten kann.

Eine kurze Geschichte von SQL

SQL wurde Anfang der 1970er-Jahre im San Jose Research Laboratory von IBM von Donald D. Chamberlin und Raymond F. Boyce entworfen. Der ursprüngliche Name war SEQUEL: Structured English Query Language, gedacht als höhere Schnittstelle zur experimentellen relationalen Datenbank System R von IBM. Das relationale Modell selbst war 1970 von Edgar F. Codd veröffentlicht worden; der Beitrag von Chamberlin und Boyce war eine Syntax, die gewöhnliche Analysten lesen konnten, an natürlichen englischen Satzteilen orientiert (SELECT … FROM … WHERE …) statt an Codds algebraischen Symbolen. Boyce (der auch der Boyce-Codd-Normalform seinen Namen geben sollte) starb 1974 im Alter von 26 Jahren, bevor die von ihm mitentwickelte Sprache kommerziell veröffentlicht wurde. Der Name wurde 1975 wegen eines Markenkonflikts mit der Marke SEQUEL von Hawker Siddeley in SQL geändert, auch wenn sich die ursprüngliche Aussprache „sequel“ in den Vereinigten Staaten neben dem internationalen „ess-cue-ell“ hält.

ANSI standardisierte SQL 1986 (SQL-86), ISO ratifizierte 1987 eine im Wesentlichen identische Version als ISO/IEC 9075, und der Standard wurde seither alle drei bis fünf Jahre überarbeitet: SQL-92 (immer noch die Grundlage, von der die meisten Tutorials ausgehen), SQL:1999 (rekursive Abfragen, Trigger), SQL:2003 (XML-Typ, MERGE), SQL:2011 (temporale Tabellen), SQL:2016 (JSON-Unterstützung) und zuletzt SQL:2023 (mehrdimensionale Arrays, Property-Graph-Abfragen). Trotz Wellen konkurrierender Technologien (Objektdatenbanken in den 1990ern, NoSQL in den späten 2000ern, Data Lakes in den 2010ern) hat sich SQL seit über fünfzig Jahren als die dominierende Abfragesprache für strukturierte Daten gehalten. Bis 2024 haben sogar die meisten NoSQL-Plattformen SQL oder SQL-ähnliche Schichten wieder eingeführt (Cassandras CQL, MongoDBs Aggregationsstufe $sql, DynamoDBs PartiQL, Spark SQL, Trino, DuckDB, BigQuery, Snowflake) und bestätigen damit Mike Stonebrakers Vorhersage, dass die Sprache jede einzelne Speicher-Engine überdauern würde.

JSON in einem Absatz

JSON (JavaScript Object Notation) wurde 2001 von Douglas Crockford spezifiziert, abgeleitet von einer Teilmenge der JavaScript-Objektliteralsyntax, und 2013 als ECMA-404 sowie 2017 als IETF RFC 8259 standardisiert. Es hat nur sechs Werttypen (string, number, boolean, null, array, object) und kein natives Konzept für Daten, Dezimalzahlen, Binärdaten oder Schemata. JSON Schema (eine separate Spezifikation, derzeit im Entwurf 2020-12) legt strukturelle und Typvalidierung darüber. Der Wert von JSON Schema für diesen Konverter: Es ist ein portables, schema-agnostisches Format, das fast jeder moderne Codegenerator und jede Validierungsbibliothek versteht.

Die mechanische Umwandlung

Eine repräsentative Eingabe:

CREATE TABLE users (
  id INT PRIMARY KEY,
  email VARCHAR(255) NOT NULL,
  signup_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  is_active BOOLEAN DEFAULT TRUE
);

Wird abgebildet auf:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "users",
  "type": "object",
  "properties": {
    "id": { "type": "integer" },
    "email": { "type": "string", "maxLength": 255 },
    "signup_at": { "type": "string", "format": "date-time" },
    "is_active": { "type": "boolean", "default": true }
  },
  "required": ["id", "email"]
}

Schritt für Schritt: die Eingabe tokenisieren, CREATE TABLE und den Tabellennamen finden, die geklammerte Spaltenliste finden, Spaltendefinitionen an Kommas der obersten Ebene aufteilen (unter Beachtung verschachtelter Klammern für Dinge wie DECIMAL(10,2) oder CHECK (x > 0)), jede Spalte in Name + Typ + Modifikatoren parsen und den SQL-Typ auf den nächstgelegenen JSON-Schema-Typ abbilden. NOT NULL wird zur Mitgliedschaft im required-Array. DEFAULT wird zu einem default-Wert. PRIMARY KEY wird üblicherweise zu einer Annotation oder zur Mitgliedschaft in required. CHECK, FOREIGN KEY, UNIQUE und Indizes werden typischerweise zu Textannotationen, weil JSON Schema kein direktes Äquivalent hat.

Das Dialektproblem

SQL ist bekanntlich eine Familie von Dialekten, nicht eine einzelne Sprache. Schon das grundlegende Quoting von Bezeichnern unterscheidet sich:

Auch die Typnamen weichen voneinander ab. INT(11) in MySQL ist ein Hinweis auf die Anzeigebreite, den PostgreSQL ablehnt. SERIAL in PostgreSQL ist eine Kurzform für INT NOT NULL AUTO_INCREMENT PRIMARY KEY; IDENTITY erfüllt dieselbe Rolle in SQL Server; SQLite verwendet AUTOINCREMENT. BOOLEAN ist in MySQL unter der Haube TINYINT(1). Geografische Typen (GEOMETRY, POINT), JSON-Spaltentypen (JSON, JSONB), Array-Typen (PostgreSQLs INTEGER[]) und Volltext-Vektortypen (VECTOR(1536) in pgvector) haben kein JSON-Schema-Äquivalent und enden als undurchsichtige String-Annotationen. BLOB- und BYTEA-Binärdaten haben keine native JSON-Darstellung; übliche Praxis ist eine Base64-Stringifizierung mit einem contentEncoding-Hinweis.

SQL-Typen vs. JSON-Typen, die Impedanz-Fehlanpassung

SQL hat ein reichhaltiges Typsystem; JSON hat sechs Werttypen und kein Schema. Wissenswert:

Wann Sie dazu greifen würden

Moderne Alternativen

Weitere Fragen

Was, wenn meine CREATE TABLE FOREIGN-KEY-Einschränkungen hat?

JSON Schema hat kein natives Fremdschlüsselkonzept. Die sauberste Darstellung ist eine eigene Annotation (z. B. eine nicht standardisierte x-foreign-key-Eigenschaft), die die referenzierte Tabelle und Spalte vermerkt. Dieser Konverter bewahrt die Beziehung als Textnotiz in der Ausgabe; wenn Sie eine vollständig formale Referenzmodellierung brauchen, ist JSON Schemas $ref plus ein separater Definitionsblock am nächsten dran, aber das ist bei Viele-zu-viele-Fällen umständlich. Für eine reichhaltigere relationale Modellierung ziehen Sie DBML oder Atlas HCL in Betracht.

Warum enthält die Ausgabe keine CHECK-Einschränkungen?

JSON Schema kann viele einfache CHECK-Einschränkungen ausdrücken, CHECK (age >= 0) wird zu {"minimum": 0}, CHECK (status IN ('a','b')) wird zu {"enum": ["a","b"]}: aber beliebige SQL-Ausdrücke in CHECK-Klauseln (Funktionsaufrufe, Joins, Unterabfragen) haben kein JSON-Schema-Äquivalent. Der Konverter erkennt die einfachen Fälle und bewahrt komplexe Einschränkungen als Textannotationen, statt sie stillschweigend zu verwerfen.

Kann ich INSERT-Zeilen in JSON umwandeln?

Nicht mit diesem Werkzeug, es bearbeitet nur die Umwandlung auf Schema-Ebene (CREATE TABLE). Für die Umwandlung auf Zeilenebene ist der richtige Ansatz meist datenbank-nativ: PostgreSQLs SELECT row_to_json(t) FROM tbl t, MySQLs JSON_OBJECT() oder der Export nach CSV und die Verwendung eines CSV-zu-JSON-Werkzeugs. mysqldump --xml, durch einen XML-zu-JSON-Konverter geleitet, ist ein weiterer gut ausgetretener Pfad.

Warum ist BIGINT ein Problem in JSON?

JavaScripts JSON.parse verwendet IEEE-754-Doubles, die nur Ganzzahlen bis 2^53 = 9.007.199.254.740.992 exakt darstellen können. Zahlen darüber verlieren an Genauigkeit. SQL-BIGINT reicht bis 2^63 ≈ 9,2 Trillionen, weit über den sicheren JSON-Ganzzahlbereich hinaus. Die plattformübergreifende Konvention, um BIGINT sicher durch JSON zu transportieren, ist, es als Zeichenkette zu serialisieren und am Ziel mit BigInt zu parsen; viele APIs (die Tweet-IDs von Twitter / X, Stripe-IDs, PostgreSQLs bigserial) tun genau das.

Werden Daten an einen Server gesendet?

Nein. Der Parser läuft in Ihrem Browser; die JSON-Ausgabe wird lokal erstellt. Eingefügtes SQL verlässt Ihr Gerät nie, was wichtig ist, wenn Ihre CREATE-TABLE-Anweisungen proprietäre Spaltennamen, interne Tabellenkonventionen oder andere Details enthalten, die Sie nicht protokolliert haben möchten. Die Seite funktioniert offline, sobald sie geladen ist.

Verwandte Tools

JSON-Formatter

JSON sofort formatieren, minifizieren und validieren.

SQL-Formatter

SQL-Abfragen formatieren und verschönern.

XML-Formatter

XML-Dokumente formatieren und validieren.