SQL-Styleguide: Best Practices für die Formatierung

Ein SQL-Styleguide ist eine Sammlung von Konventionen, die Abfragen lesbar machen und die Diffs eines Teams konsistent halten. SQL selbst kümmert das nicht: Schlüsselwörter sind unabhängig von der Groß- und Kleinschreibung, und Leerraum wird ignoriert. SELECT, select und SeLeCt laufen also alle gleich, und ein 200 Zeichen langer Einzeiler liefert exakt dieselben Zeilen wie dieselbe Abfrage, verteilt auf zwanzig eingerückte Zeilen. Stil dreht sich daher allein darum, dass Menschen die Abfrage später lesen.

Wenn Sie gerade einfach nur eine saubere Abfrage brauchen, fügen Sie sie in den SQL-Formatierer ein, wählen Ihren Dialekt und kopieren das Ergebnis. Doch erst wenn Sie die Regeln hinter dieser Ausgabe verstehen, können Sie einen Teamstandard festlegen, statt in jedem Pull Request darüber zu streiten. Dieser Leitfaden geht die Entscheidungen durch, auf die es ankommt: Schlüsselwort-Schreibweise, Einrückung und Zeilenumbrüche, Benennung, dialektspezifische Eigenheiten und wie Sie das Ganze automatisieren.

Eine kurze Einordnung vor den Details. Weil SQL Leerraum und Schreibweise ignoriert, erzwingt die Datenbank keine dieser Regeln; sie existieren nur für die Menschen, die die Abfrage lesen, prüfen und pflegen. Daraus folgt zweierlei. Erstens gibt es selten eine einzige „richtige” Antwort; meist geht es darum, eine vernünftige Konvention zu wählen und sie überall anzuwenden. Dieser Leitfaden benennt die echten Abwägungen, statt vorzugeben, ein Stil gewinne klar. Zweitens entfalten die Regeln, weil es Konventionen und keine Vorschriften sind, ihren Wert erst, wenn man sie konsequent anwendet. Deshalb läuft jeder Abschnitt am Ende auf denselben Punkt hinaus: einmal entscheiden, dann ein Werkzeug es durchsetzen lassen.

Warum SQL-Formatierung wichtig ist

Das klarste Argument für Formatierung zeigt sich im Code Review. Ein ORM oder ein Build-Schritt gibt Abfragen oft als eine einzige ununterbrochene Zeile aus:

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=true group by u.id,u.name order by orders desc

Das kann niemand prüfen. Neu formatiert wird die Struktur offensichtlich, und der Diff lässt sich Zeile für Zeile begutachten:

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 = true
GROUP BY u.id, u.name
ORDER BY orders DESC;

Beim Debuggen profitiert man genauso. Wenn Sie eine einzeilige Abfrage aus einem Slow-Query-Log kopieren und sie drei Joins sowie ein verworrenes WHERE enthält, macht vorheriges Formatieren aus dem „Wo steckt der Fehler” eine Sache von dreißig Sekunden. Das fehlerhafte Prädikat steht in seiner eigenen Zeile, die Joins sind gestapelt, und ein versehentliches kartesisches Produkt oder ein vergessener Filter springt plötzlich ins Auge, statt in einer Textwand vergraben zu bleiben. Derselbe Kniff hilft, wenn Sie SQL lesen, das ein anderes System erzeugt hat: Query Builder und Reporting-Werkzeuge sind berüchtigt dafür, korrekte, aber unlesbare Ausgaben zu produzieren.

Konsistenz ist der leisere Gewinn und mit der Zeit der wertvollste. Wenn alle gleich formatieren, zeigen Diffs nur, was sich tatsächlich geändert hat – eine neue Spalte, ein angepasster Filter – und nicht das Rauschen, bei dem die Abstandsvorlieben der einen Person gegen die der anderen ankämpfen. Die Aufmerksamkeit eines Reviewers ist begrenzt; sie an umgeformtem Leerraum zu verbrauchen, lohnt sich nicht. Konsistente Formatierung erleichtert außerdem das Einarbeiten: Eine neue Kollegin liest Abfragen, die alle gleich aussehen, lernt die Form des Teams einmal und wendet sie überall an. Nichts davon verlangt, dass jemand von Hand formatiert; das ist das Thema des letzten Abschnitts: Sie legen die Regeln fest, ein Werkzeug wendet sie an.

Eine Invariante liegt all dem zugrunde, und es lohnt sich, sie klar auszusprechen, weil sie sich durch diesen ganzen Leitfaden zieht: Formatierung ändert nur Leerraum, Zeilenumbrüche, Schlüsselwort-Schreibweise und Kommentare. Sie ändert niemals die Logik der Abfrage oder ihre Ergebnisse. Eine formatierte Abfrage ist dieselbe Abfrage. Deshalb können Sie die chaotische Version von oben gefahrlos durch den SQL-Formatierer laufen lassen, ohne sich darum sorgen zu müssen, was sie zurückgibt.

Schlüsselwort-Schreibweise – GROSSBUCHSTABEN vs. Kleinbuchstaben

Die älteste Debatte in jedem SQL-Styleguide dreht sich darum, ob reservierte Schlüsselwörter in UPPERCASE oder lowercase stehen sollten. Beides ist gültig, denn bei Schlüsselwörtern unterscheidet SQL nicht zwischen Groß- und Kleinschreibung. Die Uneinigkeit betrifft die Lesbarkeit, und es lohnt sich, beide Seiten zu verstehen, bevor Sie wählen.

Argumente für Schlüsselwörter in GROSSBUCHSTABEN

Das traditionelle Argument ist der visuelle Kontrast. Wenn man SELECT, FROM, WHERE, JOIN und GROUP BY in Großbuchstaben schreibt, heben sich die Schlüsselwörter von den kleingeschriebenen Tabellen- und Spaltennamen ab, sodass Sie die Form einer Abfrage – ihre Klauseln, ihren Aufbau – überfliegen können, ohne sich darauf zu verlassen, dass ein Editor sie einfärbt.

Das zählt mehr, als es klingt, denn SQL wandert durch reichlich Orte ohne Syntaxhervorhebung: Logdateien, E-Mail-Verläufe, Pull-Request-Beschreibungen, einen reinen Text-diff, eine Slack-Nachricht, ein Monitoring-Dashboard, einen Stacktrace. An all diesen Stellen sind Großbuchstaben bei Schlüsselwörtern das Einzige, was die Struktur lesbar hält – nimmt man die Hervorhebung weg, ist select id from users where active ein Brei aus kleingeschriebenen Wörtern, während SELECT id FROM users WHERE active auf einen Blick noch als Abfrage zu erkennen ist. Das ist die Konvention, die Sie in den meisten älteren Styleguides, in Datenbankdokumentationen und in nahezu jedem SQL-Lehrbuch finden, was auch erklärt, warum vielen Entwicklern Schlüsselwörter in Großbuchstaben vertrauter sind, selbst wenn ihr Editor sie ohnehin einfärben würde.

Argumente für Schlüsselwörter in Kleinbuchstaben

Das moderne Gegenargument lautet, dass die Syntaxhervorhebung das Kontrastproblem gelöst hat. Jeder Editor und jede IDE färbt Schlüsselwörter eindeutig ein, sodass deren Großschreibung überflüssig ist – und manchen Lesern kommt Durchgängig-Großgeschriebenes wie Schreien vor. Es geht auch geringfügig schneller zu tippen, wenn man nicht bei jedem Schlüsselwort zur Umschalttaste greifen muss.

Der Kleinschreibungs-Stil ist im Analytics Engineering verbreitet. Die dbt-Community und mehrere häufig zitierte Team-Styleguides setzen standardmäßig auf kleingeschriebene Schlüsselwörter, mit der Begründung, dass die Hervorhebung das visuelle Gewicht trägt und Kleinschreibung die Abfrage ruhiger lesbar hält. Ein feinerer Punkt spricht ebenfalls dafür: Kleingeschriebene Schlüsselwörter liegen auf derselben visuellen Ebene wie Ihre Tabellen- und Spaltennamen in snake_case, sodass sich die gesamte Abfrage als ein zusammenhängender Text liest und nicht als zwei Register – schreiende Schlüsselwörter und leise Bezeichner –, die um Aufmerksamkeit konkurrieren. Ob das ein Vorzug oder ein Nachteil ist, ist genau die Frage, bei der Teams sich uneinig sind, was uns zum einzigen Urteil bringt, das tatsächlich Bestand hat.

Das Urteil – Konsistenz schlägt die Wahl

Hier ist der Teil, auf den es wirklich ankommt: Welche Variante Sie wählen, ist weit weniger wichtig, als sich für eine zu entscheiden und sie durchzusetzen. Eine Codebasis, in der die Hälfte der Abfragen SELECT schreit und die andere Hälfte select flüstert, ist das schlechteste Ergebnis, weil die Inkonsistenz selbst zum Rauschen wird. Gemischte Schreibweise innerhalb einer einzigen Abfrage ist noch schlimmer.

Konsistenz gewinnt aus einem mechanischen Grund, nicht aus einem ästhetischen. Inkonsistente Schreibweise lässt Diffs lügen: Ein Reviewer sieht eine „geänderte” Zeile, hinter der in Wirklichkeit nur jemand steckt, der ein Schlüsselwort umformatiert hat, und die eigentliche Änderung versteckt sich im Rauschen. Auch grep und Suche werden unzuverlässiger, wenn dasselbe Schlüsselwort in drei Schreibweisen auftaucht. Ein einziger erzwungener Stil räumt diesen Mehraufwand zum Preis einer einzigen Entscheidung aus dem Weg. Entscheiden Sie also als Team, halten Sie es schriftlich fest und lassen Sie ein Werkzeug es durchsetzen, statt sich auf Disziplin zu verlassen. Der SQL-Formatierer hat ein Keywords-Steuerelement mit drei Optionen – UPPERCASE, lowercase und Preserve –, sodass Sie einen ganzen Stapel historischer Abfragen mit einem einzigen Klick auf einen Stil normalisieren können. Dieselbe Abfrage, in beiden Varianten dargestellt:

-- UPPERCASE
SELECT id, email FROM users WHERE active = true ORDER BY created_at DESC;

-- lowercase
select id, email from users where active = true order by created_at desc;

Wählen Sie die, die Ihr Team bevorzugt. Entscheidend ist, dass alle Ihre Abfragen ihr entsprechen.

Einrückung und Zeilenumbrüche

Die Schreibweise bestimmt, wie Schlüsselwörter aussehen. Einrückung und Zeilenumbrüche bestimmen, wie die Logik der Abfrage auf die Seite abgebildet wird, und hier steckt der Großteil der Lesbarkeit.

Der „Fluss”-Stil vs. Block-Stil

Simon Holywells bekannter sqlstyle.guide hat den „Fluss”-Stil (river style) populär gemacht, bei dem Schlüsselwörter rechtsbündig ausgerichtet werden, sodass ein senkrechter Kanal aus Leerraum durch die Mitte der Abfrage verläuft:

SELECT id,
       email,
       created_at
  FROM users
 WHERE active = true
 ORDER BY created_at DESC;

Der Reiz besteht darin, dass SELECT, FROM und WHERE an ihrer rechten Kante bündig stehen und die Spaltenliste sauber rechts vom Fluss sitzt. Die Nachteile sind allerdings praktischer Natur. Die Ausrichtung hängt von der Länge Ihres längsten Schlüsselworts ab, sodass das Hinzufügen eines LEFT JOIN Sie zwingen kann, alles neu einzurücken; sie ist von Hand mühsam zu pflegen; und sie erzeugt rauschende Diffs, weil das Ändern der Länge eines Schlüsselworts den Leerraum in benachbarten Zeilen verschiebt.

Der Block-Stil (oder linksbündige Stil) beginnt jede Hauptklausel am linken Rand in einer eigenen Zeile und rückt den Inhalt der Klausel ein:

SELECT
  id,
  email,
  created_at
FROM users
WHERE active = true
ORDER BY created_at DESC;

Das ist der gängige Standard und der, den die meisten Werkzeuge erzeugen, gerade weil er stabil ist: Das Hinzufügen einer Klausel formt nie die Zeilen darüber um, sodass Diffs klein bleiben und das Layout automatische Formatierung übersteht. Der Fluss-Stil optimiert dafür, wie eine fertige Abfrage isoliert aussieht; der Block-Stil optimiert dafür, wie Abfragen sich im Lauf der Zeit ändern und wie sie sich in der Versionskontrolle prüfen lassen. Für alles, was in einem Repository lebt und bearbeitet wird, ist der Block-Stil die sicherere Wahl, und von ihm geht der Rest dieses Leitfadens aus.

Wie viele Leerzeichen – 2 vs. 4 vs. Tabs

Sobald Sie einrücken, müssen Sie entscheiden, wie weit. Die drei gängigen Antworten haben jeweils ihre Begründung:

• 2 Leerzeichen – der häufigste Standard. Hält Diffs kompakt und verschachtelte Abfragen davon ab, über den rechten Bildschirmrand hinauszumarschieren.
• 4 Leerzeichen – gibt jeder Verschachtelungsebene mehr visuellen Abstand, was bei Abfragen mit tiefen Unterabfragen oder vielen CTE-Ebenen hilft.
• Tabs – lassen jeden Entwickler seine eigene Anzeigebreite wählen, ohne die Datei zu verändern.

Es gibt hier keine universell richtige Antwort, was genau der Grund ist, warum der SQL-Formatierer ein Indent-Steuerelement mit allen drei Varianten (2 spaces, 4 spaces, Tab) bietet. Wählen Sie eine und wenden Sie sie überall an.

Wo Zeilen umbrechen

Die Einrückungsbreite ist der einfache Teil. Die folgenreichere Entscheidung ist, wo Zeilenumbrüche eingefügt werden:

• SELECT-Spalten – eine Spalte pro Zeile für alles Nicht-Triviale, sodass das Hinzufügen oder Entfernen einer Spalte im Diff genau eine Zeile berührt. Sehr kurze Abfragen können in einer einzigen Zeile bleiben.
• FROM und JOIN – jeden Join in einer eigenen Zeile beginnen, wobei die ON-Bedingung entweder nachgestellt oder darunter eingerückt wird. So bleibt der Join-Graph lesbar.
• WHERE – jedes AND / OR in eine eigene Zeile setzen, sodass sich die boolesche Logik von oben nach unten lesen lässt. Bei gemischten AND/OR-Bedingungen die Gruppen klammern und einrücken, sodass die Vorrangregel explizit ist, statt etwas, das der Leser sich erarbeiten muss.

Das sind Richtlinien, keine Gesetze. Ein triviales SELECT id FROM users WHERE id = 1 braucht keine fünf Zeilen, und es auf fünf zu zwingen schadet der Lesbarkeit, statt zu helfen. Die Faustregel lautet ungefähr: Umbrechen, wenn die Abfrage mehr als eine oder zwei Spalten, mehr als eine Tabelle oder mehr als eine Bedingung hat. Darunter ist eine einzige Zeile klarer; darüber großzügig umbrechen. Ein guter Formatierer kodiert eine sinnvolle Schwelle für Sie, aber es lohnt sich, das Prinzip zu verstehen, damit die Ausgabe Sie nie überrascht.

Auf den chaotischen Einzeiler von vorhin angewendet, erzeugen diese Regeln ein Layout, in dem jede Klausel und jeder Join auf einen Blick sichtbar ist:

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 = true
GROUP BY u.id, u.name
ORDER BY orders DESC;

Führende vs. nachgestellte Kommata

Eine kleinere, aber hartnäckige Frage: Wohin gehört das Komma in einer mehrzeiligen Spaltenliste?

-- Leading commas
SELECT
    id
  , email
  , created_at
FROM users;

-- Trailing commas
SELECT
    id,
    email,
    created_at
FROM users;

Führende Kommata haben einen echten Vorteil: Das Hinzufügen oder Entfernen einer Spalte ändert eine einzige Zeile, und ein fehlendes Komma fällt leicht auf, weil die betreffende Zeile heraussticht. Nachgestellte Kommata lesen sich natürlicher und sind in der Praxis weit verbreiteter. Beide sind in Ordnung – wählen Sie eines und lassen Sie den Formatierer es anwenden, sodass niemand je wieder darüber nachdenken muss.

Namenskonventionen für Tabellen und Spalten

Formatierung regelt den Leerraum; die Benennung regelt die Bezeichner selbst, und ein Styleguide ist ohne sie unvollständig.

Der De-facto-Standard für SQL-Bezeichner ist snake_case – alles klein, Wörter durch Unterstriche getrennt: user_id, created_at, order_items. Er verdient diesen Status aus einem konkreten Grund, nicht nur aus Gewohnheit: snake_case-Bezeichner müssen nie in Anführungszeichen gesetzt werden und verhalten sich über Dialekte hinweg konsistent, während camelCase (üblich im Anwendungscode) mit der Art kollidiert, wie Datenbanken die Schreibweise umwandeln, worauf wir gleich kommen.

Es lohnt sich, ausdrücklich zu machen, warum sich das von Anwendungscode unterscheidet. In den meisten Programmiersprachen kontrolliert der umgebende Code die Bezeichner, und camelCase oder PascalCase ist die Norm. SQL-Bezeichner dagegen werden von den eigenen Schreibweisen-Umwandlungsregeln der Datenbank interpretiert, und genau diese Regeln machen gemischt geschriebene Namen fragil. snake_case umgeht das gesamte Problem: Es gibt keine Schreibweise umzuwandeln, keinen Grund zum Quoten und nichts, das sich von einer Engine zur nächsten anders verhält.

Ein paar weitere Konventionen, die in nahezu jedem SQL-Styleguide auftauchen:

• Singular vs. Plural bei Tabellennamen ist eine echte Trennlinie. users (Plural, „die Tabelle enthält Benutzer”) und user (Singular, „jede Zeile ist ein Benutzer”) haben beide ihre Befürworter. Wie bei der Schreibweise kommt es weniger auf die Wahl an als darauf, sie konsequent auf jede Tabelle anzuwenden.
• Reservierte Wörter als Bezeichner vermeiden. Eine Spalte order, user oder table zu nennen zwingt Sie, sie überall zu quoten, und lädt verwirrende Fehler ein. Greifen Sie stattdessen zu order_id oder account.
• Schlüsselbenennung konsistent halten. Ein Primärschlüssel namens id und Fremdschlüssel nach dem Muster <referenced_table>_id (etwa user_id) machen Joins vorhersehbar und selbsterklärend.

Es gibt eine Falle, die ausdrücklich erwähnt werden sollte, weil sie Teams beißt, die Datenbankspalten so benennen, wie sie Anwendungsvariablen benennen. In PostgreSQL wird ein nicht in Anführungszeichen gesetzter Bezeichner in Kleinbuchstaben umgewandelt, sodass SELECT userId FROM t tatsächlich nach einer Spalte namens userid sucht. In dem Moment, in dem Sie ihn quoten – "userId" –, bewahrt die Datenbank die Schreibweise und behandelt "userId" und userid als zwei verschiedene Spalten:

-- Erstellt eine Spalte, deren echter Name kleingeschrieben "userid" ist
CREATE TABLE t (userId integer);

-- Beide funktionieren – der Name wurde in Kleinbuchstaben umgewandelt
SELECT userId FROM t;
SELECT userid FROM t;

-- Dies schlägt fehl: "column \"userId\" does not exist"
-- Die Anführungszeichen erzwingen einen exakten, schreibungsabhängigen Treffer
SELECT "userId" FROM t;

Beachten Sie, dass verschiedene Datenbanken die Schreibweise in unterschiedliche Richtungen umwandeln – Oracle wandelt nicht in Anführungszeichen gesetzte Bezeichner in Großbuchstaben um, mehrere andere in Kleinbuchstaben –, sodass gemischt geschriebene, gequotete Bezeichner nicht einmal portabel sind. Der saubere Ausweg besteht darin, gequotete, gemischt geschriebene Bezeichner ganz zu vermeiden und bei snake_case zu bleiben, was das gesamte Problem umgeht und Ihr Schema in jedem Dialekt lesbar hält.

Für einen tieferen Vergleich von camelCase, snake_case und kebab-case – einschließlich der Frage, wann jede Variante über Code und Daten hinweg die richtige Wahl ist – siehe den Leitfaden zu Namenskonventionen.

Formatierung über SQL-Dialekte hinweg

Alles bisher ist weitgehend dialektunabhängig – Schreibweise, Einrückung, Zeilenumbrüche und Benennung gelten unabhängig davon, welche Datenbank Sie anvisieren. Doch „formatiere dieses SQL” läuft in dem Moment gegen eine Wand, in dem Ihre Abfrage Syntax verwendet, die spezifisch für eine Datenbank ist, denn ein generischer Parser, der diese Syntax nicht erkennt, verstümmelt sie: Er kann ein Token an der falschen Stelle trennen, einen Operator falsch deuten oder ein Anführungszeichen als String-Begrenzer behandeln und die halbe Abfrage verschlucken. Hier zahlt sich dialektbewusste Formatierung aus, und das ist der Grund, warum der Formatierer Sie zuerst eine Datenbank wählen lässt, statt zu raten. Die folgenden Unterschiede sind die, auf die Sie in alltäglichen Abfragen am häufigsten stoßen.

Vorgang	PostgreSQL	MySQL / MariaDB	SQL Server (T-SQL)	Oracle	Standard SQL
String-Verkettung	|| oder CONCAT()	CONCAT()	+ oder CONCAT()	|| oder CONCAT()	||
NULL-Fallback	COALESCE()	COALESCE() / IFNULL()	COALESCE() / ISNULL()	COALESCE() / NVL()	COALESCE()
Zeilenbegrenzung	LIMIT	LIMIT	TOP / OFFSET … FETCH	FETCH FIRST	FETCH FIRST
Bezeichner-Quoting	doppelte Anführungszeichen ("…")	Backticks	eckige Klammern ([…])	doppelte Anführungszeichen ("…")	doppelte Anführungszeichen ("…")

Zeichenkettenverkettung und NULL-Behandlung

Zwei der häufigsten Alltagsoperationen werden über Dialekte hinweg unterschiedlich geschrieben.

Zeichenkettenverkettung:

-- PostgreSQL, Oracle, SQLite (standard operator)
SELECT first_name || ' ' || last_name AS full_name FROM users;

-- SQL Server (T-SQL uses +)
SELECT first_name + ' ' + last_name AS full_name FROM users;

-- Portable across dialects
SELECT CONCAT(first_name, ' ', last_name) AS full_name FROM users;

NULL-Rückfallwerte:

-- Standard SQL (works everywhere)
SELECT COALESCE(nickname, name) AS display_name FROM users;

-- SQL Server only
SELECT ISNULL(nickname, name) AS display_name FROM users;

-- MySQL / MariaDB only
SELECT IFNULL(nickname, name) AS display_name FROM users;

Ein auf den falschen Dialekt eingestellter Formatierer versteht ISNULL oder den ||-Operator möglicherweise nicht und kann die umgebende Abfrage falsch parsen.

Zeilenbegrenzung und Bezeichner-Quoting

Das Begrenzen der Ergebniszeilen ist eines der dialektabweichendsten Syntaxstücke:

-- PostgreSQL, MySQL, SQLite
SELECT id, name FROM users ORDER BY created_at DESC LIMIT 10;

-- SQL Server (T-SQL)
SELECT TOP 10 id, name FROM users ORDER BY created_at DESC;

-- Standard SQL / Oracle
SELECT id, name FROM users ORDER BY created_at DESC FETCH FIRST 10 ROWS ONLY;

Auch das Quoten von Bezeichnern teilt sich in drei Wege. Wenn Sie einen Bezeichner quoten müssen – meist, um ein reserviertes Wort zu verwenden oder die Schreibweise zu bewahren –, hängt der Begrenzer von der Datenbank ab:

-- MySQL / MariaDB use backticks
SELECT `order`, `user` FROM `select`;

-- SQL Server (T-SQL) uses square brackets
SELECT [order], [user] FROM [select];

-- Standard SQL (PostgreSQL, Oracle, SQLite) uses double quotes
SELECT "order", "user" FROM "select";

Ein Formatierer, der glaubt, MySQL-Backticks seien String-Begrenzer oder T-SQL-Klammern seien etwas anderes, erzeugt fehlerhafte Ausgaben. Die Dialekt-Einstellung ist das, was ihm sagt, was was ist. Das ist auch der Grund, warum das Kopieren und Einfügen einer Abfrage zwischen Datenbanken selten ein sauberer Tausch ist: Dieselbe logische Absicht – zwei Strings verketten, auf NULL zurückfallen, auf zehn Zeilen begrenzen, ein reserviertes Wort quoten – wird über die Dialekte hinweg auf vier verschiedene Arten geschrieben, und nur der Parser, der Ihre Datenbank kennt, kann sie neu formatieren, ohne sie zu beschädigen.

Warum dialektbewusste Formatierung wichtig ist

Genau deshalb wird der SQL-Formatierer mit neun Dialekten ausgeliefert – PostgreSQL, MySQL, SQL Server (T-SQL), BigQuery, Snowflake, Oracle, SQLite, MariaDB und Standard SQL – statt mit einem einzigen generischen Modus. Den richtigen auszuwählen bedeutet, dass der Parser PostgreSQL-Dollar-Quoting-Strings und ::-Casts, T-SQL-Klammerbezeichner und TOP, warehouse-spezifische Funktionen in BigQuery und Snowflake sowie die obigen Quoting-Regeln korrekt verarbeitet, statt zu raten und sie falsch zu machen. Wählen Sie vor dem Formatieren Ihre tatsächliche Datenbank aus dem Dropdown, und die Ausgabe kommt korrekt und idiomatisch zurück.

SQL-Formatierung automatisieren

Die Regeln zu lesen ist eine Sache; sie von Hand anzuwenden sollte niemand. Der ganze Sinn eines Styleguides ist, dass eine Maschine ihn durchsetzt. Es gibt drei Stellen, an denen man Formatierung einbinden kann, je nachdem, wie viel Reibung Sie beseitigen wollen.

In Ihrem Editor (Format on Save)

Die aufwandsärmste Option ist, bei jedem Speichern automatisch zu formatieren. VS Code hat SQL-Formatierer-Erweiterungen, die beim Speichern laufen, und JetBrains DataGrip sowie die Datenbankwerkzeuge in anderen IDEs liefern einen eingebauten Formatierer mit, den Sie an einen Tastendruck oder einen Speicher-Hook binden können. Einmal eingerichtet, sind Ihre Abfragen schlicht nie unformatiert – dasselbe Modell wie Prettier für JavaScript oder gofmt für Go. Der Haken ist, dass Editor-Einstellungen auf der Maschine jedes Entwicklers liegen, sodass Format on Save Ihr SQL ordentlich hält, aber von sich aus nicht garantiert, dass der Rest des Teams das auch tut. Dafür brauchen Sie die nächste Ebene.

In CI mit einem Linter

Um Stil über ein ganzes Team durchzusetzen, verlagern Sie die Prüfung in die Continuous Integration. Ein SQL-Linter wie sqlfluff lintet und behebt automatisch zugleich: Sie kodieren Ihre Regeln – Dialekt, Schlüsselwort-Schreibweise, Einrückung, Kommaplatzierung – in einer .sqlfluff-Konfigurationsdatei, führen sqlfluff lint aus, um Verstöße zu markieren, und sqlfluff fix, um sie zu reparieren, und lassen die CI jeden Pull Request scheitern, der vom vereinbarten Stil abweicht. Das ist dieselbe Idee wie ESLint oder Prettier, die ein Frontend-Repo abriegeln: Stil hört auf, ein Review-Kommentar zu sein, den sich jemand merken muss, und wird zu einer bestandenen oder fehlgeschlagenen Prüfung, die die Maschine nie vergisst. Der Lohn ist, dass Stildebatten einmal stattfinden, wenn Sie die Konfiguration schreiben, statt in jedem Pull Request.

Einmalige Online-Formatierung

Manchmal haben Sie einfach nur eine hässliche Abfrage und keine Lust, irgendetwas zu installieren – ein Schnipsel aus einem Log, die Slack-Nachricht eines Kollegen, eine Abfrage, die Sie in eine Dokumentation einfügen. Dafür fügen Sie sie in den SQL-Formatierer ein, wählen Dialekt, Schreibweise und Einrückung und kopieren das saubere Ergebnis.

Der Datenschutz spielt hier eine Rolle und wird leicht übersehen. Viele Online-Formatierer senden den eingefügten Text zur Verarbeitung an einen Server, sodass eine Kopie Ihrer Abfrage – Tabellennamen, Spaltennamen, manchmal wörtliche Werte aus einem Produktionsvorfall – Ihre Maschine verlässt. Der SQL-Formatierer läuft vollständig in Ihrem Browser, sodass Ihr SQL nie irgendwohin hochgeladen wird. Das macht es sicher, Abfragen zu formatieren, die Produktionsschemata oder geschützte Logik berühren – genau die Situation, in der Sie saubere Formatierung am dringendsten wollen und Ihre Abfrage am wenigsten einem Dritten überlassen möchten. Wenn Sie im selben Workflow mit anderen Formaten ringen, funktioniert der verwandte JSON-Formatierer genauso – dieselbe Verarbeitung im Browser, dasselbe Kopieren per Klick.

Die drei Ansätze schließen sich nicht gegenseitig aus, und das beste Setup kombiniert sie meist: Format on Save für die schnelle innere Schleife beim Schreiben, einen CI-Linter als Rückhalt, der den Teamstandard durchsetzt, und einen Online-Formatierer für die Wegwerf-Schnipsel, die nie Ihr Repo berühren. Wozu Sie auch greifen, denken Sie ein letztes Mal an die Invariante – keines dieser Werkzeuge ändert, was Ihre Abfrage tut. Sie ordnen Leerraum, Zeilenumbrüche, Schreibweise und Kommentare um, und sonst nichts.

Häufig gestellte Fragen

Sollten SQL-Schlüsselwörter groß- oder kleingeschrieben werden?

Beides ist gültig, denn bei SQL-Schlüsselwörtern spielt die Groß- und Kleinschreibung keine Rolle. UPPERCASE lässt Schlüsselwörter in Umgebungen ohne Syntaxhervorhebung hervorstechen, etwa in Logs und Diffs; lowercase ist leichter zu tippen und passt zu modernen Editoren, die Schlüsselwörter ohnehin einfärben. Worauf es wirklich ankommt: Das ganze Team wählt eine Variante, und ein Formatierer setzt sie durch – gemischte Schreibweise ist die schlechteste Wahl.

Was ist die beste Einrückung für SQL?

Zwei Leerzeichen sind der häufigste Standard und halten Diffs kompakt; vier Leerzeichen machen tief verschachtelte Abfragen leichter lesbar; Tabs lassen jeden Entwickler seine eigene Anzeigebreite wählen. Es gibt keine einzige richtige Antwort – wählen Sie eine und wenden Sie sie im ganzen Team konsequent an. Die meisten SQL-Formatierer, dieser eingeschlossen, unterstützen alle drei Optionen.

Wie formatiere ich SQL automatisch?

Es gibt drei Wege, SQL automatisch zu formatieren: Format on Save in Ihrem Editor (VS Code oder DataGrip), einen Linter in der CI wie sqlfluff, der den Stil automatisch korrigiert, oder einen Online-SQL-Formatierer zum einmaligen Einfügen. Der Online-Weg ist am schnellsten, weil er keine Installation braucht – einfach einfügen, Dialekt wählen und Ergebnis kopieren.

Sollte ich in SQL führende oder nachgestellte Kommata verwenden?

Führende Kommata (Komma am Zeilenanfang) liefern beim Hinzufügen oder Entfernen von Spalten sauberere Diffs und machen ein fehlendes Komma leicht erkennbar; nachgestellte Kommata (Komma am Zeilenende) lesen sich natürlicher und sind verbreiteter. Beides ist in jedem SQL-Styleguide akzeptabel – entscheidend ist, eines zu wählen und einen Formatierer es automatisch anwenden zu lassen.

Ändert das Formatieren von SQL, wie die Abfrage läuft?

Nein. Das Formatieren von SQL ändert nur Leerraum, Zeilenumbrüche, Schlüsselwort-Schreibweise und Kommentare – es ändert nie die Logik der Abfrage. Eine formatierte Abfrage liefert exakt dieselben Ergebnisse wie das Original, weshalb es völlig sicher ist, selbst Produktionsabfragen vor dem Prüfen oder Ausführen aufzuhübschen.

Welche Namenskonvention sollte ich für SQL-Tabellen und -Spalten verwenden?

snake_case – alles klein mit Unterstrichen – ist der De-facto-Standard für SQL-Tabellen- und -Spaltennamen, weil es das Quoten vermeidet und über Dialekte hinweg sicher bleibt. Benennen Sie Primärschlüssel (id) und Fremdschlüssel (user_id) konsistent und vermeiden Sie reservierte Wörter wie order oder user als Bezeichner, um Quoting-Kopfschmerzen vorzubeugen.

Wie formatiere ich SQL für einen bestimmten Dialekt wie PostgreSQL oder T-SQL?

Wählen Sie zuerst den passenden Dialekt im Formatierer aus. Der PostgreSQL-Modus verarbeitet ::-Casts und Dollar-Quoting-Strings korrekt; der SQL-Server-Modus (T-SQL) versteht Klammerbezeichner [identifiers] und TOP. Den falschen Dialekt zu wählen lässt einen generischen Parser dialektspezifische Syntax verstümmeln, stellen Sie ihn daher vor dem Formatieren immer auf Ihre echte Datenbank ein.

Gibt es einen Standard-SQL-Styleguide?

Es gibt keinen offiziellen Standard, aber mehrere viel zitierte: Simon Holywells sqlstyle.guide und die öffentlichen Styleguides von Teams wie Mozilla und der dbt-Community. Ihr gemeinsamer Konsens – konsistente Einrückung, snake_case-Bezeichner und ein Zeilenumbruch vor jeder Hauptklausel – ist das, was dieser Leitfaden kodifiziert, und ein Formatierer kann ihn für Sie durchsetzen.