Zum Hauptinhalt springen
Yunknow Toolbox

← Zurück zum Blog

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.

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.

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

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.

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.

#sql#dev