SQL-Abfragen formatieren _

Wie SQL-Formatierung funktioniert

SQL-Formatierung ist eine lexergesteuerte Umschreibung, die jeden Token in der Abfrage durchläuft und ihn mit den richtigen Leerzeichen gemäß den Regeln des gewählten Dialekts neu ausgibt. Die Abfragesemantik ändert sich nie, nur das Layout.

1. Dialekt auswählen. MySQL-Backticks, PostgreSQL-Casts ::, BigQuery-Tabellenpfade mit Punkten und T-SQL-Bezeichner in eckigen Klammern erfordern jeweils einen Tokenisierer, der sie kennt. Der Dialekt-Selektor wählt aus, welche Grammatik angewendet wird.
2. Eingabe tokenisieren. Der Formatierer zerlegt die Abfrage in einen Token-Stream: Schlüsselwörter (SELECT, JOIN), Bezeichner, Literale, Operatoren, Klammern und Kommentare. String-Literale und gequotete Bezeichner werden unverändert durchgereicht, damit dialektspezifische Syntax weiterhin funktioniert.
3. Layout-Regeln anwenden. Klauseln auf oberster Ebene (SELECT, FROM, WHERE, GROUP BY, ORDER BY) beginnen auf einer eigenen Zeile. Durch Komma getrennte Ausdrücke in der Select-Liste und Spaltenlisten erhalten jeweils eine eigene Zeile, eingerückt um die gewählte Einrückungseinheit.
4. Schlüsselwort-Schreibweise anwenden. Der Schreibweise-Selektor schreibt erkannte SQL-Schlüsselwörter in Groß- oder Kleinbuchstaben um oder behält die ursprüngliche Schreibweise bei. Bezeichner werden nie angefasst — Spalten- und Tabellennamen erscheinen immer so, wie sie geschrieben wurden.
5. Formatierten String ausgeben. Der Token-Stream wird mit dem Einrückungszeichen (2 Leerzeichen, 4 Leerzeichen oder Tabulator) und der konfigurierten Umbruchregel wieder zu einem einzigen String zusammengesetzt. Der Live-Modus führt die gesamte Pipeline mit einem 200-ms-Debounce erneut aus, während du tippst.

Warum SQL verschönern

• Lesbarkeit von Pull-Request-Diffs. Ein 200-zeiliger CTE, der auf eine einzige Zeile umgeschrieben wird, verwandelt ein Code-Review in ein Ratespiel. Konsistente Formatierung hält den Diff auf die eigentliche Änderung beschränkt — eine neue Spalte, ein zusätzlicher JOIN, ein anderes WHERE-Prädikat — damit der Reviewer es erkennt, ohne sich durch Leerzeichen kämpfen zu müssen.
• Einfacheres Debuggen. Wenn eine Abfrage die falsche Zeilenanzahl zurückgibt, liest man sie zuerst Zeile für Zeile durch. Formatiertes SQL platziert jeden JOIN auf einer eigenen Zeile und richtet WHERE-Prädikate aus, sodass ein fehlendes AND oder ein verirrtes OR sofort ins Auge fällt.
• Einheitlicher Teamstil. Die meisten Teams übernehmen einen SQL-Styleguide (dbt Labs, GitLab und Mode Analytics veröffentlichen alle ihre eigenen) und möchten, dass jede commitete Abfrage diesen befolgt. Ein Formatierer, der vor dem Commit ausgeführt wird, entfernt den Stilstreit aus dem Review und lässt nur die Logik übrig.
• SQL in Dokumentation teilen. Runbooks, Incident-Retros und Notion-Dokumente profitieren von SQL, das man von oben nach unten lesen kann. Formatiertes SQL lässt sich sauber in einen Fenced-Code-Block einfügen und wird in PDF-Exporten vorhersehbar gedruckt, ohne unschöne Zeilenumbrüche mitten in einem Schlüsselwort.

Häufige Anwendungsfälle

SQL-Formatierung taucht in Analytics-Engineering, Backend-Entwicklung und Betrieb auf, wann immer eine Abfrage von jemandem gelesen werden muss, der sie nicht geschrieben hat.

• Analytics-Engineering: Pre-Commit-Hook in einem dbt-Projekt, der jede Modelldatei neu formatiert, damit PR-Diffs auf Logikänderungen beschränkt bleiben und kein Leerzeichen-Rauschen entstehen.
• Datenbankadministration: einen einzeiligen Slow-Query-Log-Eintrag einfügen, formatieren und die Join-Reihenfolge durchgehen, während man die Incident-Retro schreibt.
• Dokumentation: eine Abfrage aus einem Looker-Explore oder einer Tableau-Arbeitsmappe holen, für ein Runbook formatieren und als kopierbares Beispiel für die Bereitschaftsrotation einbetten.

Ein konkretes Beispiel

Füge SELECT u.id,u.email,COUNT(o.id) FROM users u LEFT JOIN orders o ON o.user_id=u.id WHERE u.created_at > '2024-01-01' GROUP BY u.id,u.email ORDER BY u.id; in das Eingabefeld ein, mit Dialekt PostgreSQL, Einrückung 2 Leerzeichen und Schreibweise GROSSBUCHSTABEN. Die Ausgabe setzt SELECT, FROM, LEFT JOIN, WHERE, GROUP BY und ORDER BY jeweils auf eine eigene Zeile; jede Spalte in der Select-Liste und der Group-by-Liste erhält ihre eigene eingerückte Zeile; und das ON-Prädikat liegt eine Einrückungsebene tiefer als das JOIN-Schlüsselwort, zu dem es gehört.

FAQ

Welche SQL-Dialekte werden unterstützt?

Das Dialekt-Dropdown umfasst Standard-SQL, MySQL, PostgreSQL, SQLite, MariaDB, Transact-SQL (SQL Server / Azure SQL), BigQuery, Snowflake und Redshift. Die zugrundeliegende sql-formatter-Bibliothek erkennt außerdem DuckDB, Spark SQL, Hive, Trino, Db2, N1QL, PL/SQL, ClickHouse, TiDB und SingleStoreDB — den nächstgelegenen Dialekt zu wählen liefert sinnvolle Ergebnisse, selbst wenn das genaue Ziel nicht in der Liste ist. Bezeichner, String-Literale und dialektspezifische Operatoren (PostgreSQL @>, BigQuery-Präfixe SAFE.) werden unverändert beibehalten.

Validiert dieses Tool mein SQL?

Nein. Der Formatierer ist ein lexikalischer Umschreiber, kein Parser. Er tokenisiert die Eingabe, wendet Layout-Regeln an und gibt das Ergebnis aus; er prüft nicht, ob die Abfrage semantisch korrekt ist, ob die referenzierten Tabellen existieren oder ob die Syntax im gewählten Dialekt legal ist. Führe die formatierte Ausgabe durch die echte Datenbank (oder einen SQL-Linter wie SQLFluff) für eine echte Korrektheitsprüfung.

Warum werden meine Schlüsselwörter großgeschrieben?

Das Dropdown für die Schlüsselwort-Schreibweise ist standardmäßig auf GROSSBUCHSTABEN eingestellt, was der Konvention der meisten veröffentlichten SQL-Styleguides entspricht (dbt Labs, Mode, GitLab). Wechsle zu kleinbuchstaben, wenn dein Team select / from in Kleinbuchstaben schreibt, oder zu Beibehalten, wenn die Ausgabe die eingegebene Schreibweise behalten soll. Bezeichner sind nie betroffen — nur der erkannte Schlüsselwortsatz wird umgeschrieben.

Wird meine Abfrage irgendwo hochgeladen?

Nein. Die eingebettete sql-formatter-Bibliothek läuft in deinem Browser, die Formatierung findet lokal auf deiner Maschine statt und der Abfragetext verlässt das Netzwerk nie. Die einzigen ausgehenden Anfragen dieser Seite sind dieselben Analytics- und Werbeanfragen, die jede Seite auf tools.ultim8soft.com stellt; der SQL-Text selbst ist kein Bestandteil davon.

Schön formatiertes SQL hört auf, ein Stilstreit zu sein, sobald ein Formatierer es übernimmt. Das Tool läuft vollständig in deinem Browser, die Abfrage verlässt die Seite nie, und derselbe dialektbewusste Tokenisierer, der das npm-Paket sql-formatter antreibt, führt die Umschreibung durch.