Strukturierung und Formatierung von SQL Statements — der Cluster-Pfad

Ein komplexes SQL-Statement ist schon schwer genug zu lesen — wechselnde Coding-Styles im selben File machen jede Zeile zur zusätzlichen Re-Orientierungs-Übung. SQL-Formatierung ist deshalb Team-Verantwortung, kein persönliches Geschmacksthema.

Kurzüberblick:

Coding-Style ist Team-Verantwortung, keine persönliche Geschmacksfrage — divergente Stile in einem File sind ein konkretes Wartbarkeits-Problem.
Vier Lesbarkeits-Achsen mit eigenen Vertiefungen: Editor-Konfiguration, Bezeichner und Delimiter, Statement-Aufbau, Kommentierung.
Auto-Formatter ergänzen, ersetzen aber nicht den Lern-Effekt manueller Formatierung.
2026er-Einordnung: Multi-Editor-Welt, sqlfluff und pgFormatter als Linter, manuelles Re-Formatieren als KI-Code-Versteh-Hebel.

Voraussetzung: SQL Server 2017+ oder Postgres 12+ — SSMS bleibt 2018er Referenz-Editor, die Prinzipien gelten für jeden SQL-Editor mit Block-Selection.

Vorgeschichte: 2.000 Zeilen, drei Stile

Vor einiger Zeit habe ich eine umfangreiche Prozedur mit bald 2.000 Zeilen Code überarbeitet — drei Entwickler hatten nacheinander an ihr gearbeitet. Sie enthielt zu ca. 30 Tabellen unterschiedlich umfangreiche Statements, die im Wesentlichen alle die gleiche Aufgabe hatten. Die SQL-Statements je Tabelle hätten alle ähnlich aussehen können. Tatsächlich gab es Abweichungen von Entwickler zu Entwickler und auch innerhalb der Arbeit eines einzelnen Entwicklers, die jeweils unterschiedlich auf Lesbarkeit und Wartbarkeit drückten:

Wurden Begrenzungsbezeichner (Delimiter) verwendet?
Wie sieht es mit Groß-/Kleinschreibung von Schlüsselwörtern und Funktionsnamen aus?
Wurden bei Entitäts-/Tabellen-Wechseln Inline-Kommentare eingefügt?
Sind eher temporäre Tabellen oder Tabellen-Variablen zu verwenden?
…

In den vergangenen 20 Jahren meiner Tätigkeit als Consultant sind viele Versuche, Regeln für Formatierung und Strukturierung von Quellcode aufzustellen, gescheitert oder von kontroversen Diskussionen begleitet worden. Wer im Laufe seines Entwicklerlebens eigene Präferenzen entwickelt hat, akzeptiert neue Vorgaben selten gern — der Mensch als Gewohnheitstier scheint damit häufig überfordert.

Die Reformat-Falle

Bei dem Review einer anderen Prozedur, die von einem geschätzten Kollegen geschrieben wurde, hatte mir die verwendete Strukturierung und Formatierung gar nicht zugesagt. Ohne mir Gedanken über die Folgen zu machen, hatte ich die Prozedur während des Reviews kurzerhand umformatiert. Inhaltlich war sie korrekt und fehlerfrei. Durch den Eincheck-Vorgang wurde sie aber als geändert markiert — und nach der umfangreichen Reformatierung war im Diff nicht mehr zu erkennen, ob auch funktional etwas geändert wurde.

Kritik habe ich mir anhören müssen, zu Recht. Reformat-Commits gehören separat — niemals vermischt mit Substanz-Edits. Sonst zerstört der Style-Pass die Reviewbarkeit des inhaltlichen Diffs.

Auch 2026 ist der Built-in-Formatter in SSMS — und in den meisten anderen SQL-Editoren — nur eine Layout-Stütze, kein Style-Guide. Die Style-Definition bleibt Team-Verantwortung.

Die vier Achsen der SQL-Lesbarkeit

Diese Artikel-Serie nimmt die vier Kern-Achsen der SQL-Code-Lesbarkeit auseinander — pro Achse ein eigener Vertiefungs-Artikel, hier zusammengefasst als Pfad-Vorstellung:

Achse 1 — Editor-Konfiguration. Der Boden, auf dem alles steht: Tab vs. Space, Zeilennummern, Wort-Wrap, Block-Selection. Ohne diese Fundamente sind die folgenden Achsen mühsam.
Achse 2 — Bezeichner, Delimiter, Aliase. Die Vokabel-Ebene: T01 oder CustomerHist, [brackets] oder nichts, Komma-Position vor oder nach der Spalte.
Achse 3 — Statement-Aufbau: SELECT, WHERE, FROM , JOIN. Die Grammatik-Ebene: wie man SELECT-Klauseln, WHERE-Bedingungen und JOIN-Reihenfolgen so layoutet, dass die Daten-Struktur sichtbar wird.
Achse 4 — Kommentierung. Die Meta-Ebene: Inline- und Block-Kommentare in 2.000-Zeilen-Statements, damit das nächste Review nicht bei Null anfängt.

Reihenfolge des Cluster-Pfads

Die vier Achsen lassen sich getrennt vertiefen, bauen aber aufeinander auf:

Editor zuerst. Bezeichner-Konventionen sind ohne funktionierenden Editor mit Block-Selection mühsam — wer fünf Zeilen gleichzeitig anpassen muss, will nicht fünfmal Copy-Paste machen.
Bezeichner danach. Statement-Struktur lässt sich nur dann konsequent layouten, wenn die Bezeichner-Konventionen (Aliase, Delimiter, Komma-Position) stehen.
Statement-Aufbau drittens. Erst wenn die einzelnen Statements lesbar sind, lohnt sich die Investition in saubere Kommentierung — sonst verstecken Kommentare die zugrundeliegende Struktur, statt sie zu erläutern.
Kommentierung zuletzt. Die Meta-Ebene gewinnt erst dann, wenn das Statement selbst klar genug ist, was gemeint ist — Kommentare adressieren dann das warum.

Formatieren 2026

Multi-Editor-Welt

SSMS bleibt Microsoft-Default, aber 2026 ist die SQL-Editor-Welt deutlich breiter geworden:

VS Code mit der mssql-Extension — seit dem Azure-Data-Studio-Retirement Microsofts offizieller Cross-Platform-SQL-Editor. Bietet Multi-Cursor, exzellente Source-Control-Integration und integriertes Schema Compare / Schema Designer / GitHub-Copilot.
Azure Data Studio — Microsofts Cross-Platform-Alternative zu SSMS, am 28. Februar 2026 abgekündigt. Bestehende Installationen funktionieren weiter, erhalten aber keine Updates oder Security-Patches mehr. Microsoft empfiehlt die Migration auf die VS Code mssql-Extension (eingebautes Migrations-Toolkit für Connections und Settings).
DataGrip (JetBrains) für Multi-Engine-DBA-Arbeit — kommerziell, mit starkem SQL-Parser und Echtzeit-Refactoring.
DBeaver als Open-Source-Multi-Engine-Tool — die Free Community Edition reicht für die meisten Fälle.
pgAdmin für Postgres-zentrische Stacks.

Was sie gemeinsam haben: Multi-Cursor und Block-Selection als modernes Pendant zur SSMS-Spaltenauswahl — ALT+Klick in VS Code, Strg+Alt+Klick in DataGrip. Die Block-Selection-Argumentation aus Achse 1 gilt 2026 multi-tool, nicht mehr SSMS-only.

Auto-Formatter ergänzen, ersetzen nicht

Während 2018 jeder Style-Pass manuell laufen musste, gibt es 2026 etablierte Multi-Dialekt-Formatter:

sqlfluff — Linter und Formatter für T-SQL, Postgres, Snowflake, BigQuery, DuckDB und weitere Dialekte. Konfigurierbar via .sqlfluff-File, CI-tauglich, mit dbt-Integration.
pgFormatter — spezialisierter Postgres-Formatter (Perl-basiert), als CLI und Online-Tool.
sql-formatter und Prettier-Plugins für SQL (prettier-plugin-sql, prettier-plugin-sql-cst) — für SQL-Snippets in Web-Stacks (Frontend-/Backend-Mixed-Repos).

Was diese Tools nicht leisten: Style-Definition. Sie erzeugen Layout nach einer Konfiguration — die Konfiguration selbst (Komma-Position, JOIN-Einrückung, Alias-Schreibweise) bleibt Team-Entscheidung. Die vier Achsen sind damit nicht obsolet, sondern werden via Tool durchgesetzt.

„Formatieren ist Lernen“ im KI-Zeitalter

Die These ist alt: manuelles Formatieren zwingt zum vollständigen Lesen und zum Aufbau eines mentalen Modells der Daten- und Tabellen-Struktur. Einrücken, Aliase ausrichten und Klammern setzen funktionieren nur, wenn man weiß, welche Tabelle worauf joint und welche Spalten zusammengehören.

2026 wiegt das doppelt — denn generierter SQL-Code aus Copilot, Cursor und LLM-Tools sieht oft technisch korrekt aus, beantwortet aber die fachliche Frage trotzdem nicht. Ein Statement, das gegen die richtigen Tabellen läuft, aber LEFT JOIN statt INNER JOIN verwendet, liefert syntaktisch korrekte Ergebnisse mit semantisch falscher Zeilen-Anzahl. Wer den generierten Code manuell durchformatiert — Spalten ausrichtet, JOIN-Bedingungen anschaut, Aliase prüft — versteht das Statement an einer Stelle, wo das pure Copy-Paste-aus-LLM-zu-Editor-ausgeführt-Pattern es nie tun würde.

Auto-Formatter ersetzen den Lern-Effekt nicht. Manuelles Re-Formatieren ist eine niedrigschwellige Lern-Hebel-Methode — auch im Code-Review-Kontext, wo der Reviewer den fremden Code beim Re-Formatieren strukturell durchgeht.

Take-Away

SQL-Formatierung ist Team-Verantwortung, kein persönlicher Geschmack — divergente Stile in einem File sind ein konkretes Wartbarkeits-Problem.
Vier Achsen — Editor, Bezeichner, Statement-Aufbau, Kommentierung — gehören zusammen, lassen sich aber getrennt vertiefen und bauen aufeinander auf.
Auto-Formatter wie sqlfluff und pgFormatter erzeugen Layout, ersetzen aber nicht den Lern-Effekt manueller Formatierung.
Im KI-Zeitalter ist manuelles Re-Formatieren ein niedrigschwelliger Hebel, um generierten Code wirklich zu verstehen — Layout-Pass als Verständnis-Pass.

FAQ

Warum manuell formatieren, wenn sqlfluff das automatisch macht?

Weil Layout-Erzeugung und Lern-Effekt verschiedene Dinge sind. sqlfluff rückt ein und richtet aus — der Schreiber dazu nicht. Beim manuellen Formatieren liest man jede Zeile, baut das mentale Modell der Tabellen-Beziehungen auf und merkt, wo ein JOIN nicht passt. Auto-Formatter sind Layout-Stütze, nicht Lern-Werkzeug — siehe Sektion „Formatieren ist Lernen“ oben.

In welcher Reihenfolge soll ich die vier Sub-Artikel lesen?

Editor → Bezeichner → Statement-Aufbau → Kommentierung. Jede Achse setzt auf der vorigen auf: Bezeichner-Konventionen brauchen funktionierende Block-Selection, Statement-Struktur braucht stabile Aliase, und Kommentierung gewinnt erst, wenn das Statement selbst klar genug ist. Siehe Sektion „Reihenfolge des Cluster-Pfads“ oben.

Was ist der Unterschied zwischen Strukturierung und Formatierung?

Formatierung ist das Layout — Einrückung, Komma-Position, Aliase, JOIN-Reihenfolge. Strukturierung ist die übergeordnete Architektur — wie man eine 2.000-Zeilen-Prozedur in lesbare Sub-Statements gliedert, wie Helper-Funktionen ausgelagert werden, wie Kommentar-Header das Big-Picture markieren. Formatierung ist Vokabel-Ebene, Strukturierung ist Aufsatz-Ebene.

Wie etabliere ich einen Coding-Style-Guide in einem Team, das schon Jahre ohne arbeitet?

In drei Schritten. Erstens: ein bestehendes Multi-Style-File als Beispiel nehmen und die divergenten Stile zeigen — das macht das Problem konkret. Zweitens: Style-Punkte einzeln durchgehen und Team-Entscheidung treffen, nicht von oben verordnen. Drittens: sqlfluff-Konfiguration als Anker fixieren und in CI hängen, sodass neue Code-Reviews nicht mehr über Layout streiten. Wichtig: Reformat-Pass auf Bestandscode immer in einem separaten Commit ohne Substanz-Edits — siehe Sektion „Die Reformat-Falle“ oben.

Funktionieren die Empfehlungen auch in Postgres oder nur in SQL Server?

Beides. Die vier Achsen sind dialekt-neutral. Konkrete Tool-Empfehlungen unterscheiden sich (sqlfluff für Multi-Dialekt, pgFormatter für Postgres-spezifisch), und die Bezeichner-Konvention ist beim Postgres-Default snake_case strenger als bei SQL Server. Die Strukturierungs-Argumente gelten 1:1 in beiden Welten.