Wie Sie SQL-Abfragen formatieren

Unordentliches SQL ist eine der schnellsten Möglichkeiten, Fehler einzuführen. Wenn eine Abfrage eine einzige lange Zeile ohne Einrückung ist, ist es schwer zu sehen, welche Bedingungen für welche Joins gelten, wo Unterabfragen beginnen und enden, oder ob die Logik korrekt ist. Ein browserbasierter Formatierer erledigt die gesamte Arbeit lokal, ohne Ihre Abfragen auf einen Server hochzuladen.

Warum Formatierung wichtig ist

• Debugging: Eine gut formatierte Abfrage macht Logikfehler sichtbar. Sie können den Fluss von SELECT zu WHERE zu JOIN verfolgen, ohne zu raten.
• Code-Review: Reviewer können formatiertes SQL in Sekunden lesen. Eine einzeilige Abfrage zwingt sie, sie zuerst mental zu analysieren.
• Wartung: Wenn Sie eine Abfrage Monate später erneut besuchen, sagt Ihnen die Formatierung auf einen Blick, was sie tut.
• Zusammenarbeit: Konsistente Formatierung in einem Team bedeutet, dass jeder SQL gleich liest.
• Onboarding: Neue Teammitglieder können formatiertes SQL lesen, ohne die mündliche Geschichte jeder Abfrage zu benötigen.
• Dokumentation: Wenn SQL in Design-Dokumenten, Runbooks oder Wikis erscheint, sind formatierte Abfragen für Nicht-Entwickler leichter zu folgen.
• Versionskontroll-Diffs: Formatiertes SQL produziert sauberere Diffs, wenn Sie eine Klausel ändern, ohne die ganze Abfrage neu zu formatieren.

So formatieren Sie SQL

1. Fügen Sie Ihr SQL ein: Geben Sie eine minifizierte oder unordentliche Abfrage in den Formatierer ein. Er behandelt SELECT, INSERT, UPDATE, DELETE, CREATE TABLE und komplexe Abfragen mit Unterabfragen und Joins.
2. Optionen konfigurieren: Wählen Sie die Einrückungsgröße und ob Schlüsselwörter in Großbuchstaben geschrieben werden sollen. Diese Einstellungen entsprechen dem Styleguide Ihres Projekts.
3. Ergebnis kopieren: Das formatierte SQL ist bereit, in Ihren Editor, Datenbankclient oder Ihre Dokumentation zurückgepasten zu werden.

Wie gute Formatierung aussieht

Eine Abfrage wie select u.name, o.total from users u join orders o on u.id = o.user_id where o.total > 100 and u.active = 1 order by o.total desc wird zu:

SELECT
  u.name,
  o.total
FROM users u
JOIN orders o
  ON u.id = o.user_id
WHERE o.total > 100
  AND u.active = 1
ORDER BY o.total DESC

Jede Klausel beginnt in ihrer eigenen Zeile. Bedingungen sind unter ihrer übergeordneten Klausel eingerückt. Joins und ihre ON-Bedingungen sind klar gepaart.

Eine kurze Geschichte der SQL-Formatierungskonventionen

SQL wurde 1974 von den IBM-Forschern Donald Chamberlin und Raymond Boyce entwickelt, ursprünglich SEQUEL (Structured English Query Language) genannt. Das «QL» im ursprünglichen Namen spiegelte die Absicht wider, dass sich die Sprache wie Englisch lesen sollte. Von Anfang an implizierte dieses menschenlesbare Design eine Konvention: Rücken Sie Ihre Klauseln ein, damit sie von oben nach unten wie Sätze gelesen werden.

Während des größten Teils der 1980er und 1990er Jahre wurde SQL von Hand in Texteditoren geschrieben und die Formatierung war persönlich. Einige Werkstätten übernahmen den «Fluss-Stil» (bei dem jedes Schlüsselwort vertikal an der rechten Seite einer virtuellen Spalte ausgerichtet ist), andere verwendeten den «ägyptischen Stil» (geschweifte-Klammer-in-derselben-Zeile-Äquivalent), und die meisten verwendeten einfach das, was der Autor bevorzugte.

Der erste weit verbreitete SQL-Formatierer war Apex SQL Formatter (2000), gefolgt von Devarts SQL Complete (2002) und Red Gates SQL Prompt (2003). Diese Tools brachten Formatierung auf IDE-Ebene zu SQL Server- und Oracle-Entwicklern. Bis 2010 hatte jede große IDE (SSMS, DataGrip, DBeaver) integrierte SQL-Formatierung, und Online-Formatierer wurden Standard für ad-hoc-Bereinigung.

2017 änderte sich das Formatierer-Ökosystem mit sql-formatter (npm), einer Open-Source-JavaScript-Bibliothek, die die meisten browserbasierten SQL-Formatierer heute antreibt, einschließlich diesem. Moderne Formatierer behandeln Dialekt-Unterschiede (MySQL-Backticks, PostgreSQL-Fensterfunktionen, SQL-Server-eckige-Klammern) und produzieren konsistente, konfigurierbare Ausgabe.

Von großen Unternehmen verwendete SQL-Styleguides

Die meisten professionellen Codebasen folgen einem von mehreren veröffentlichten SQL-Styleguides:

Wenn Sie ein neues Projekt starten, wählen Sie einen der etablierten Guides. Wenn Sie einer bestehenden Codebasis beitreten, folgen Sie dem, was bereits da ist. Konsistenz innerhalb eines Projekts ist wichtiger als irgendein spezifischer Stil.

Häufige Formatierungsoptionen

• Schlüsselwort-Groß-/Kleinschreibung: GROSSBUCHSTABEN (am häufigsten, macht Schlüsselwörter visuell unterscheidbar), Kleinbuchstaben (moderner dbt/Snowflake-Stil) oder Originalfall (manche IDEs behalten bei, was Sie eingegeben haben).
• Bezeichner-Groß-/Kleinschreibung: snake_case ist der Standard in PostgreSQL und den meisten Unix-freundlichen Datenbanken; PascalCase oder camelCase in Oracle/SQL-Server-Traditionen.
• Einrückung: 2 Leerzeichen (kompakt, passt in 80-Zeichen-Terminal), 4 Leerzeichen (entspricht den meisten Code-Styleguides) oder Tabs (selten in SQL).
• Komma-Platzierung: nachgestellte Kommas (nach jeder Spalte in separater Zeile) oder führende Kommas (Komma am Anfang der nächsten Zeile, einfacher zum Hinzufügen/Entfernen von Spalten).
• Zeilenlänge: 80 Zeichen (terminal-freundlich), 120 Zeichen (moderner IDE-Standard) oder unbegrenzt (weniger üblich in Produktion).
• JOIN-Stil: ANSI JOIN-Schlüsselwort (bevorzugt) vs alter Stil mit kommagetrennten FROM und WHERE-Join-Bedingungen (veraltet).
• Unterabfrage-Formatierung: Unterabfragen in Klammern einrücken, Common Table Expressions (CTEs) für Klarheit verwenden oder mit expliziten Aliasen verschachteln.

Dialekt-Unterschiede

SQL-Formatierer müssen dialektspezifische Syntax behandeln:

Ein guter Formatierer erkennt oder akzeptiert einen Dialekt-Hinweis und behandelt dann Syntax, die andere Dialekte ablehnen würden.

Häufige Stolperfallen

• Neuformatierung innerhalb von Produktionsskripten: Das Ändern von Leerzeichen in einem Migrationsskript, das bereits teilweise angewendet wurde, kann Probleme verursachen, wenn Ihr Migrations-Tool per Hash Fingerabdruck nimmt. Formatieren Sie vor der ersten Ausführung.
• String-Literale neuformatiert: Eine mehrzeilige Zeichenfolge innerhalb einer Abfrage sollte nicht vom SQL-Formatierer neuformatiert werden; einige naive Formatierer brechen inline-Strings.
• Kommentare verloren oder verschoben: SQL-Kommentare (einzeilige Bindestriche und mehrzeilige Schrägstrich-Sterne) müssen die Formatierung überleben. Einige Formatierer löschen sie oder verschieben sie auf verwirrende Weise.
• Bezeichner-Zitierung geändert: Doppelt zitierte Bezeichner in PostgreSQL oder Backtick-Bezeichner in MySQL haben spezifische Bedeutungen. Ein Formatierer, der durch das Entfernen von Anführungszeichen «normalisiert», kann das Verhalten der Abfrage ändern, wenn der Bezeichner Anführungszeichen benötigt (reserviertes Wort, gemischte Groß-/Kleinschreibung in PostgreSQL).
• Fensterfunktionen falsch formatiert: OVER (PARTITION BY x ORDER BY y) sollte lesbar bleiben. Aggressives Zeilenumbruch innerhalb von Fensterfunktion-Klammern produziert unordentliche Ausgabe.
• CTE-Ketten überindentiert: WITH cte1 AS (...), cte2 AS (...) kann von einigen Formatierern zu tief verschachtelt werden. Die meisten modernen Formatierer halten CTEs auf der obersten Ebene.
• Dollar-quotierte Strings (PostgreSQL-Funktionen): In $$ eingewickelte Funktionskörper sollten ihren Inhalt nicht neuformatiert haben. Einige Formatierer verstümmeln sie.
• Anbieterspezifische Schlüsselwörter falsch klassifiziert: Ein Formatierer, der QUALIFY (Snowflake) oder LATERAL (PostgreSQL) nicht kennt, kann sie möglicherweise nicht korrekt großschreiben oder ausrichten.
• Stored Procedures mit Kontrollfluss: BEGIN/END-, IF/THEN/ELSE-Blöcke in T-SQL oder PL/SQL benötigen andere Einrückungsregeln als reine Abfragen.

Tipps

• Vor dem Commit formatieren: Lassen Sie Ihr SQL durch einen Formatierer laufen, bevor Sie es zur Versionskontrolle hinzufügen. Dies hält Diffs sauber und Reviews auf Logik konzentriert, nicht auf Stil.
• Konsistente Schlüsselwort-Groß-/Kleinschreibung verwenden: Wählen Sie Schlüsselwörter in Groß- oder Kleinbuchstaben und bleiben Sie dabei in Ihrem gesamten Projekt. Stile zu mischen macht Abfragen schwerer zu lesen.
• Komplexe Abfragen aufbrechen: Wenn eine Abfrage nach der Formatierung immer noch schwer zu lesen ist, erwägen Sie, sie in CTEs (Common Table Expressions) oder Views aufzubrechen. Formatierung kann fundamental komplexe Logik nicht beheben.
• Syntax-Hervorhebung überprüfen: Ein guter Formatierer bietet farbcodierte Hervorhebung, die Schlüsselwörter, Strings und Zahlen visuell unterscheidbar macht, was hilft, Tippfehler zu erkennen.
• Nur ändern, was Sie ändern: In einer großen bestehenden Codebasis erzeugt das gleichzeitige Neuformatieren von allem einen riesigen Diff, der echte Änderungen verschleiert. Formatieren Sie inkrementell, während Sie Abfragen berühren.
• Richten Sie Ihren Editor ein: VS Code (SQLTools, vscode-sql-formatter), DataGrip, DBeaver und pgAdmin haben alle integrierte oder erweiterungsbasierte Formatierer. Einmal konfigurieren und vergessen.
• Achten Sie auf groß-/kleinschreibungssensitive Datenbanken: PostgreSQL ist groß-/kleinschreibungssensitiv für zitierte Bezeichner. Ein Formatierer, der die Groß-/Kleinschreibung zitierter Bezeichner ändert, wird Abfragen brechen.
• Formatierte Abfrage testen: Nach dem Neuformatieren führen Sie die Abfrage aus, um zu überprüfen, dass die Ausgabe unverändert ist. Die meisten Formatierer sind zuverlässig, aber ein Fehler im Formatierer kann eine Abfrage beschädigen.
• CTEs statt verschachtelter Unterabfragen verwenden: Eine CTE-Kette ist fast immer einfacher zu lesen und zu debuggen als die entsprechende verschachtelte Unterabfrage, sogar nach der Formatierung.

Datenschutz und vertrauliche Abfragen

Der SQL-Formatierer läuft vollständig in Ihrem Browser. Die Abfragen, die Sie einfügen, die Zwischenverarbeitung und die formatierte Ausgabe bleiben alle auf Ihrem Gerät. Nichts wird auf einen Server hochgeladen, protokolliert oder mit irgendjemandem geteilt.

Dies ist wichtig, weil SQL-Abfragen oft extrem sensible Informationen enthalten: Tabellennamen, die die Produktarchitektur enthüllen, Spaltennamen, die Geschäftslogik und Metriken offenlegen, echte Kunden-IDs in WHERE-Klauseln, interne API-Endpunkte in Stored Procedures, SSNs und Kreditkartennummern in Testdaten, Mitarbeitervergütung in HR-Abfragen, Finanzzahlen in Analytics-Abfragen, Kunden-E-Mail-Adressen in Marketing-Abfragen. Cloud-SQL-Formatierer protokollieren jede Abfrage in ihren Anfrageprotokollen, behalten sie manchmal zur «Service-Verbesserung» und waren an echten Verstößen beteiligt, bei denen eingefügte Produktionsabfragen sensible Schemata und Daten preisgaben. Ein browserbasierter Formatierer hat null Exposition: Die Abfrage verlässt niemals Ihren Computer.

Browserbasierte Formatierung funktioniert auch offline, sobald die Seite geladen ist, nützlich für die Formatierung von Abfragen in Flugzeugen, in sicheren Umgebungen ohne Internetzugang oder überall dort, wo Sie eine Datenbankabfrage nicht in einen Drittanbieterdienst einfügen können oder sollten.