Warum SQL-Formatierung wichtig ist (und was ein Formatierer tut)

Ein ORM loggt eine Abfrage, und sie landet als eine 300-Zeichen-Zeile in deiner Konsole. Ein Formatierer macht aus dieser Textwand eine eingerückte, überschaubare Abfrage, in der jede Klausel ihren Platz hat. Es ist dieselbe Abfrage — nur lesbar. Hier steht, was tatsächlich passiert.

Eine lange Zeile hinein, eine lesbare Abfrage heraus. Wir haben unserem SQL-Formatierer dies in einer Zeile gegeben: select u.id,u.name,count(o.id) as orders from users u left join orders o on o.user_id=u.id where u.active=1 group by u.id,u.name having count(o.id)>2 order by orders desc. Zurück kam jede Klausel auf eigener Zeile, die ausgewählten Spalten unter select eingerückt — und, das ist der Punkt, Leerzeichen um = und >, sodass aus o.user_id=u.id ein o.user_id = u.id wurde. Beachte: Die Schlüsselwörter wurden nicht großgeschrieben. Das ist eine separate Option, denn Groß-/Kleinschreibung ist Stil, Einrückung nicht.

Was Formatierung ändert (und was nicht)

Formatierung berührt nur Leerraum, Zeilenumbrüche und Einrückung — plus optional die Schreibung der Schlüsselwörter. Sie setzt SELECT, FROM, WHERE, JOIN und GROUP BY in eigene Zeilen, rückt Spalten und Bedingungen ein und richtet die Struktur so aus, dass Verschachtelung offensichtlich wird.

Was sie nie ändert: deine Tabellen, Spalten, Werte oder Logik. Eine formatierte Abfrage liefert exakt dasselbe Ergebnis wie die gequetschte. Das heißt auch: Formatierung ist keine Validierung — sie sagt dir nicht, ob eine Spalte falsch geschrieben ist oder die Abfrage wirklich läuft.

Dialekte: warum das Tool nach der Datenbank fragt

SQL hat einen Standard, aber jede Datenbank ergänzt ihre eigene Note, und der Formatierer muss wissen, welche, um korrekt zu parsen:

• Bezeichner-Quotierung — MySQL nutzt Backticks (`col`); PostgreSQL und Standard-SQL doppelte Anführungszeichen ("col").
• Zeilenbegrenzung — LIMIT in MySQL/SQLite/PostgreSQL, TOP im SQL Server.
• Umwandlungen — PostgreSQLs value::int hat anderswo keine Entsprechung.

Wählst du den falschen Dialekt, werden diese falsch geparst, und die Einrückung stimmt nicht. Wähle im SQL-Formatierer deine tatsächliche Datenbank, bevor du einfügst.

Großgeschriebene Schlüsselwörter: Stil, keine Regel

Viele Teams schreiben Schlüsselwörter groß (SELECT, FROM), damit sie sich von Tabellen- und Spaltennamen abheben. SQL selbst ist bei Schlüsselwörtern unabhängig von der Schreibweise, das ist also reine Lesbarkeitskonvention — ein Formatierer wendet sie mit einem Klick auf die ganze Abfrage einheitlich an.

Die Schreibweise ist das eine, was unser SQL-Formatter bewusst unangetastet lässt. Eine kleingeschriebene Abfrage, formatiert:

select
  *
from
  users
where
  id = 1

und dieselbe Form in Großschreibung getippt:

SELECT
  id,
  name
FROM
  t
WHERE
  a = 1
  AND b = 2

Kleines select bleibt klein, großes SELECT bleibt groß. Standard ist preserve, denn Keywords umzuschreiben ist Hausstil und keine Korrektur — und es stillschweigend zu ändern würde den Diff eines reinen Formatierungs-Commits unprüfbar machen, das Einzige, was ein Formatter niemals tun darf.

Warum lokal?

Ein clientseitiger Formatierer parst und druckt das SQL in deinem Browser neu. Deine Abfragen — die oft Schema und Geschäftslogik verraten — verlassen nie deinen Rechner.

Verwandte Tools

• Räumst du stattdessen JSON auf? Nutze den JSON-Formatter.
• Abfrageergebnisse zwischen Formaten verschieben? Probiere JSON ⇄ CSV ⇄ Excel.

Vorher und nachher

Dieselbe Abfrage — von einem ORM in eine Zeile gepresst und dann formatiert:

select u.id,u.name,count(o.id) as orders from users u left join orders o on o.user_id=u.id where u.active=1 group by u.id,u.name having count(o.id)>0 order by orders desc;

Formatiert liest sich die Struktur von oben nach unten:

SELECT
    u.id,
    u.name,
    COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.active = 1
GROUP BY u.id, u.name
HAVING COUNT(o.id) > 0
ORDER BY orders DESC;

Gleiches Ergebnis, aber Joins, Filter und Gruppierung sind jetzt auf einen Blick erkennbar.

Was die Formatierung ändert, ist die Lage der Umbrüche. Ein auf eine Zeile gequetschtes INSERT kommt so zurück:

insert into
  logs (a, b)
values
  (1, 2)

Das Klausel-Keyword nimmt eine eigene Zeile, sein Operand wird darunter eingerückt, die Spaltenliste behält ihre Kommas in der Zeile. Das ist der ganze Algorithmus — eine Klausel pro Zeile, Operanden eingerückt — und sobald man ihn vorhersagen kann, wird eine formatierte Datei allein nach Form prüfbar: ein WHERE, das nicht am linken Rand steht, ist ein WHERE in einer Unterabfrage.

Kommas am Zeilenanfang oder -ende

Zwei gängige Spaltenstile: nachgestellte Kommas (u.id, am Zeilenende) oder vorangestellte Kommas (, u.name am Zeilenanfang). Vorangestellte Kommas halten Diffs in der Versionsverwaltung sauberer — eine neue Spalte ändert eine Zeile statt zwei —, aber beide sind gültig, und die meisten Formatierer lassen dir die Wahl. Einheitlichkeit im Projekt zählt mehr als die Seite, die du wählst.

Häufige Fragen

• Beeinflusst Formatierung die Performance? Nein. Der Parser ignoriert unbedeutenden Leerraum und die Schreibung von Schlüsselwörtern, eine formatierte Abfrage ist für die Engine also äquivalent. Nur der Inhalt von String-Literalen ist je leerraum-empfindlich.
• Sollte ich formatiertes SQL committen? Für Views, Migrationen und Stored Procedures ja — ein einheitlicher Stil hält Diffs klein und Reviews schnell.
• Formatierung repariert aber keine kaputte Abfrage. Sie ordnet nur Text um; Fehler findest du mit einer echten Datenbank oder einem Linter. Ergebnisse danach exportieren? Siehe JSON in CSV und Excel umwandeln.