Kostenloser SQL-Formatter

SQL, eine kurze Geschichte der Sprache, die formatiert wird

SQL (Structured Query Language) wurde bei IBM von Donald D. Chamberlin und Raymond F. Boyce in den frühen 1970ern entwickelt, ursprünglich als SEQUEL („Structured English Query Language“), nach einem Markenrechtskonflikt in SQL umbenannt. Erstmals kommerzialisiert wurde die Sprache 1979 vom Vorläufer von Oracle (Relational Software, Inc.), Oracle V2 war die erste kommerzielle SQL-Datenbank und kam vor IBMs eigenem DB2 auf den Markt. Der erste ANSI-Standard, ANSI SQL-86, wurde 1986 veröffentlicht; die deutlich umfassendere Revision SQL-92 (der „große“ SQL-Standard, ISO/IEC 9075:1992) definierte den Großteil der Syntax, die moderne Anwender wiedererkennen, JOIN-Syntax, Mengenoperationen, Subqueries, Transaktionen. Spätere Revisionen ergänzten objekt-relationale Features (SQL:1999), XML-Unterstützung (SQL:2003), Window-Funktionen und CTEs (SQL:2003 und 2008), temporale Abfragen (SQL:2011), JSON-Unterstützung (SQL:2016, in SQL:2023 erweitert). Jeder große Datenbank-Hersteller implementiert seinen eigenen Dialekt, MySQL, PostgreSQL, SQLite, Microsoft SQL Server (T-SQL), Oracle (PL/SQL), DuckDB (PostgreSQL-kompatibles analytisches SQL), BigQuery, Snowflake, Redshift, ClickHouse, Databricks SQL: alle teilen den SQL-92-Kern, weichen aber bei Funktionen, Syntax-Erweiterungen und reservierten Wörtern voneinander ab. Ein guter Formatter respektiert den Dialekt, den er formatiert, weil derselbe Bezeichner in einem Dialekt ein Schlüsselwort und in einem anderen ein erlaubter Spaltenname sein kann.

Konventionen, die SQL lesbar machen

Mehrere Konventionen haben sich in SQL-Style-Guides etabliert, Mozillas, Simon Holywells viel zitierter SQL Style Guide, die Konventionen des GitLab-Datenteams, dbts empfohlener Stil. Schlüsselwörter in GROSSBUCHSTABEN (SELECT, FROM, WHERE, JOIN) gegenüber Bezeichnern (Tabellen- und Spaltennamen) in Kleinbuchstaben oder snake_case ist die dominierende Konvention. Manche Style-Guides plädieren für das Gegenteil (kleingeschriebene Schlüsselwörter sind leichter zu tippen und zu lesen), und die Dialekt-Dokumentation von PostgreSQL selbst verwendet durchgehend Kleinbuchstaben, aber GROSSBUCHSTABEN setzen sich in den meisten professionellen Codebases durch, weil sie die Sprachstruktur auf einen Blick erkennbar machen. Jede Hauptklausel auf einer eigenen Zeile: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, jede beginnt eine neue Zeile auf demselben Einrückungsniveau. JOIN-Bedingungen unter ON eingerückt: das Schlüsselwort JOIN auf eigener Zeile, das Schlüsselwort ON auf der nächsten Zeile, eine Stufe eingerückt. Komma am Anfang oder am Ende bei Spaltenlisten ist ein langjähriger Stil-Streit; Komma am Anfang (jede Spaltenzeile beginnt mit dem Komma) erzeugt bei Spalten-Hinzufügen/Entfernen sauberere Diffs und schützt vor dem Trailing-Comma-Syntaxfehler, wirkt aber für viele optisch ungewohnt. Komma am Ende ist im Produktionscode häufiger. Subquery-Einrückung: verschachtelte Abfragen werden eine Stufe tiefer eingerückt als ihre Eltern. CTE (WITH)-Klauseln: jede benannte CTE auf eigener Zeile, der Body unter dem AS eingerückt, die Hauptabfrage darunter linksbündig.

Wann du zu einem SQL-Formatter greifst

• Lesen von Abfragen, die ein ORM geloggt hat. Hibernate, Sequelize, ActiveRecord, Prisma, SQLAlchemy, Django ORM, alle erzeugen SQL programmatisch und geben es als einzelne dichte Zeile in deine Anwendungslogs. Um „warum ist diese Abfrage langsam?“ zu debuggen, fügst du das geloggte SQL in den Formatter ein und liest, was das ORM tatsächlich produziert hat. Das Ergebnis ist oft erhellend („ah, das ist ein CROSS JOIN, wo ich einen INNER erwartet hatte“).
• Code Review bei Datenbank-PRs. Eine SQL-Migration oder eine Stored-Procedure-Änderung lässt sich viel leichter reviewen, wenn sie konsistent formatiert ist. Schicke die Datei vor dem Commit durch den Formatter, damit der Diff strukturell und kein Whitespace-Rauschen ist.
• EXPLAIN-Pläne neben der Abfrage lesen. Beim Tuning einer langsamen Abfrage liest du die EXPLAIN-Ausgabe, dann liest du die Abfrage erneut, um die Tabellenreferenz oben im Plan zu finden. Eine formatierte Abfrage macht den Querverweis sofort möglich.
• SQL in Tickets, Docs, Slack einfügen. Eine formatierte Abfrage liest sich sauber; eine einzeilige minifizierte Abfrage ist in jedem schmalen Kontext unleserlich. Vor dem Teilen formatieren.
• Reformatieren von Legacy-Abfragen mit gemischter Schlüsselwort-Schreibung. Eine 15 Jahre alte Codebase, in der SELECT mal als Select, mal als select, mal als SELECT geschrieben wurde, liest sich besser, nachdem der Formatter alles auf eine Konvention normalisiert hat.
• Aufräumen exportierter Abfragen aus BI-Tools. Looker, Mode, Metabase, Tableau und ähnliche Tools lassen dich das zugrunde liegende SQL kopieren, geben es aber in einem ad-hoc Format aus, das sie selbst erzeugen. Vor dem Lesen formatieren.

Das SQL-Formatter-Ökosystem

Für Kommandozeilen- und Editor-integrierte Workflows gibt es mehrere ausgereifte Optionen. sql-formatter (npm-Paket, ursprünglich von Andriy Isayev, jetzt von einem Community-Team gepflegt) ist der dominierende SQL-Formatter im JavaScript-Ökosystem, unterstützt MySQL, PostgreSQL, SQLite, Standard SQL, BigQuery, Redshift, Snowflake, Spark, TiDB, MariaDB und mehrere andere Dialekte. pg_format (Gilles Darold) ist der kanonische PostgreSQL-spezifische Formatter, in Perl geschrieben und mit dem populären Webdienst pgFormatter ausgeliefert. Poor Man's T-SQL Formatter (Tao Klerks, 2011) zielt speziell auf Microsoft SQL Servers T-SQL-Dialekt. sqlparse (Andi Albrecht) ist die Standard-Python-Bibliothek, von Django zur Abfrage-Analyse und von zahllosen Data-Engineering-Skripten verwendet. SQLFluff ist der moderne Linter-und-Formatter, der sich in dbt-Projekte und Analytics-Workflows integriert. JetBrains' DataGrip und das SQL-Plugin für IntelliJ IDEA bringen einen ausgefeilten dialekt-bewussten Formatter mit; SQLTools für VS Code und mehrere andere Erweiterungen verpacken die npm-sql-formatter-Bibliothek. Für Projekte mit einer Build-Pipeline ist das moderne Muster „Format-on-save im Editor + ein CI-Check, der den Build zum Scheitern bringt, wenn SQL-Dateien fehlerhaft formatiert sind“, dasselbe Modell wie Prettier für JavaScript oder Black für Python.

Dialekt-Unterschiede, die fürs Formatieren wichtig sind

Die meisten SQL-Formatter funktionieren mit kleineren Anpassungen über Dialekte hinweg, aber eine Handvoll Unterschiede setzen voraus, dass der Formatter weiß, welchen Dialekt er liest. Quotierte Bezeichner: Standard-SQL verwendet doppelte Anführungszeichen ("order"); MySQL verwendet standardmäßig Backticks (`order`) und respektiert doppelte Anführungszeichen nur im ANSI-Modus; SQL Server verwendet eckige Klammern ([order]). String-Verkettung: Standard-SQL verwendet ||; MySQL verwendet CONCAT() oder das selten gesehene || im ANSI-Modus; SQL Server verwendet +. Pagination: MySQL/PostgreSQL/SQLite verwenden LIMIT/OFFSET; SQL Server verwendet TOP oder OFFSET FETCH; Oracle verwendet FETCH oder ROWNUM. Auto-increment: AUTO_INCREMENT in MySQL, SERIAL oder IDENTITY in PostgreSQL, IDENTITY in SQL Server, AUTOINCREMENT in SQLite. Listen reservierter Wörter divergieren, eine Spalte namens rank muss in PostgreSQL gequotet werden (wo RANK ein Window-Funktions-Schlüsselwort ist), in MySQL ist sie als Bezeichner unproblematisch. Ein Formatter, der den Dialekt nicht kennt, kann gültige Abfragen kaputt machen, indem er unangebrachtes Quoting hinzufügt. Die „Format SQL“-Ausgabe eines generischen Formatters ist für die Standardform SELECT/INSERT/UPDATE/DELETE meist korrekt; bei herstellerspezifischer Syntax (Window-Funktionen, Hints, System-Funktionen) prüfe die Ausgabe stichprobenartig gegen die Doku deines Dialekts.

Datenschutz: Warum Browser-only besonders bei SQL zählt

SQL-Abfragen gehören in jeder Organisation zu den sensibelsten Texten: Sie offenbaren interne Tabellennamen (die die Produkt-Taxonomie verraten), Spaltennamen (die das Datenmodell verraten), Filterwerte (die echte Nutzer-IDs, E-Mail-Adressen, Geschäfts-IDs enthalten können), in älteren Mustern eingebettete Klartext-Credentials und die Struktur von Analysen, die das Unternehmen für vertraulich halten kann. Server-seitige SQL-Formatter nehmen eine Kopie jeder Abfrage in ihre Logs auf. Dieser Formatter läuft komplett in deinem Browser über JavaScript, verifiziere im Network-Tab der DevTools, während du auf Format klickst (es feuert keine Anfrage), oder schalte die Seite nach dem Laden offline (Flugmodus), und der Formatter funktioniert weiter. Sicher für Produktionsabfragen mit echten Tabellennamen und PII-Filterwerten, internes analytisches SQL, ETL-Pipelines oder jede Abfrage, die du nicht auf der Festplatte eines Fremden sehen wolltest.

Häufige Fragen

Kann der Formatter SQL-Schlüsselwörter automatisch in Großbuchstaben setzen?

Ja, der Keywords-Schalter steuert die Schreibweise. GROSSBUCHSTABEN ist die dominierende professionelle Konvention, weil sie die Sprachstruktur auf einen Blick erkennbar macht (SELECT, FROM, WHERE heben sich von Bezeichnern ab); Kleinbuchstaben werden von einigen Style-Guides bevorzugt (PostgreSQLs eigene Doku verwendet durchgehend Kleinbuchstaben) mit der Begründung, dass es leichter zu lesen und schneller zu tippen ist. Beides funktioniert, solange dein Team sich für eine Variante entscheidet und sie konsistent verwendet. Die Großschreibung hat keinen Einfluss auf das Abfrageverhalten, SQL-Schlüsselwörter sind beim Parsen case-insensitiv.

Wie passe ich die Einrückung an?

Das Indent-Dropdown unterstützt 2 Leerzeichen (die dominierende moderne Web-Konvention), 4 Leerzeichen (in älteren Java- und .NET-Shops noch üblich) oder Tab-Zeichen. 2 Leerzeichen setzen sich in neueren Codebases und speziell für SQL durch, weil tiefe Subquery-Verschachtelung bequemer in eine 100-Zeichen-Zeilengrenze passt. Halte dich an die Konvention, die dein Team bereits verwendet; Konsistenz zählt mehr als die konkrete Wahl.

Funktioniert das mit großen Abfragen?

Ja, weil das Formatieren in deinem Browser läuft, ist die praktische Obergrenze der verfügbare Speicher deines Geräts. Hunderte SQL-Zeilen werden in deutlich unter einer Sekunde formatiert; Abfragen mit mehreren tausend Zeilen (typisch in Data-Warehouse-ETL) funktionieren, können aber den Tab kurz einfrieren, während der Parser die Struktur durchläuft. Für Batch-Reformatierung eines kompletten SQL-Repositories sind Kommandozeilen-Tools (sql-formatter via npm, pg_format für PostgreSQL, SQLFluff für dbt-Projekte) angemessener.

Erkennt der Formatter meinen spezifischen SQL-Dialekt?

Er behandelt die gängigen SELECT/INSERT/UPDATE/DELETE/JOIN/CTE/Subquery-Formen über MySQL, PostgreSQL, SQLite, T-SQL und Standard-ANSI-SQL hinweg korrekt. Herstellerspezifische Syntax (Window-Funktions-Klauseln, MERGE-Statements, dialekt-spezifische Hints, System-Funktionen, Array-Operatoren im PostgreSQL-Stil, T-SQL-XML-Methoden) kann unvollkommen formatiert werden. Stichprobenartig prüfen und die formatierte Abfrage durch deine Datenbank laufen lassen, um zu bestätigen, dass sie korrekt parst, bevor du committest.

Wird mein SQL hochgeladen?

Nein. Das Formatieren läuft komplett in deinem Browser, eingefügte Abfragen verlassen dein Gerät nie. Verifiziere im Network-Tab der DevTools, während du auf Format klickst (es feuert keine Anfrage), oder schalte die Seite nach dem Laden offline (Flugmodus). Sicher für Produktionsabfragen mit sensiblen Tabellennamen, PII-Filterwerten oder jedes SQL, das unter NDA oder Compliance-Vorschriften fällt.

Verwandte Tools