10 Tipps für lesbare SQL-Abfragen: Schreib Code, den auch du in 6 Monaten noch verstehst

Du öffnest eine SQL-Datei, die du vor einem halben Jahr geschrieben hast – und verstehst nur Bahnhof. Tabellen mit kryptischen Namen, Zeilen, die endlos ineinanderfließen, und Abfragen, die auf den ersten Blick völlig unlogisch wirken. Kommt dir das bekannt vor?

Genau dieses Problem entsteht, wenn SQL-Code ohne Struktur und klare Lesbarkeit geschrieben wird. Solange die Abfrage funktioniert, wirkt es im Moment oft egal, wie sie aussieht. Doch die Konsequenzen zeigen sich spätestens dann, wenn du oder jemand aus deinem Team die Abfrage später ändern, debuggen oder erweitern muss. Unlesbarer SQL-Code ist:

  • fehleranfällig, weil logische Zusammenhänge schwer erkennbar sind,
  • zeitaufwendig zu verstehen und anzupassen,
  • teuer in der Wartung, gerade in größeren Projekten,
  • ein Hindernis für saubere Teamarbeit.

Die gute Nachricht: Lesbarer SQL-Code ist kein Hexenwerk. Mit einigen wenigen, aber wirkungsvollen Regeln kannst du deine Abfragen deutlich klarer, verständlicher und damit auch robuster machen.

In diesem Artikel zeige ich dir 10 Tipps, die deine SQL-Abfragen von „What was I thinking?“ zu „Crystal clear!“ verwandeln werden.

Lesbarer SQL Code

Tipp 1: Konsistente Groß- und Kleinschreibung

SQL ist nicht case-sensitive, aber für die Lesbarkeit ist eine klare und einheitliche Schreibweise entscheidend. Wenn du dich an eine feste Konvention hältst, erkennst du sofort, was ein SQL-Schlüsselwort ist und was ein Spalten- oder Tabellenname. Eine verbreitete Empfehlung lautet:

  • SQL-Schlüsselwörter wie SELECT, FROM, WHERE in GROSSBUCHSTABEN schreiben.
  • Tabellen- und Spaltennamen in Kleinbuchstaben oder im snake_case-Format halten.

Bad Practice

select Name, Created_At from Users;

Good Practice

SELECT name, created_at
FROM users;

Schon kleine Unterschiede in der Schreibweise können SQL-Code unruhig und schwerer lesbar machen. Eine konsequente Groß- und Kleinschreibung sorgt dagegen für Klarheit und eine bessere visuelle Struktur.

Tipp 2: Struktur durch Zeilenumbrüche und Einrückungen

Lange, durchgehende SQL-Abfragen sind schwer zu lesen und zu verstehen. Durch das Einfügen von Zeilenumbrüchen und Einrückungen wird der Code sofort klarer und die logische Struktur der Abfrage sichtbar. Eine gute Regel ist:

  • Jede Hauptklausel (SELECT, FROM, WHERE, JOIN, GROUP BY) in eine neue Zeile schreiben.
  • Unterabfragen und ON-Bedingungen einrücken, um die Hierarchie zu verdeutlichen.

Bad Practice

SELECT id,name,email,created_at FROM users INNER JOIN orders ON users.id = orders.user_id WHERE status='active';

Good Practice

SELECT id,
       name,
       email,
       created_at
FROM users
INNER JOIN orders
       ON users.id = orders.user_id
WHERE status = 'active';

Durch klare Zeilenumbrüche und Einrückungen siehst du auf einen Blick, welche Teile der Abfrage zusammengehören. Das erleichtert das Debugging und macht den Code für andere Teammitglieder verständlich.

Tipp 3: Aliasse clever verwenden – aber nicht zu clever

Aliasse helfen, lange Tabellen- oder Spaltennamen abzukürzen und Abfragen kompakter zu machen. Wichtig ist, dass sie kurz, aber aussagekräftig sind. Vermeide kryptische Abkürzungen wie a, b oder c1, da sie das Verständnis erschweren.

  • Kurze Aliasse: us für users, ord für orders
  • Aliasse klar und konsistent verwenden, besonders bei mehreren Tabellen in einem Join

Bad Practice

FROM orders a
JOIN customers b
ON a.cust_id = b.cust_id;

Good Practice

FROM orders ord
INNER JOIN customers cust
       ON ord.cust_id = cust.cust_id;

Mit aussagekräftigen Aliassen bleibt der SQL-Code leicht verständlich und die Beziehungen zwischen den Tabellen sofort erkennbar.

Tipp 4: Der Sargnagel: SELECT *

Viele Anfänger greifen gerne auf SELECT * zurück, weil es einfach ist. Das mag im ersten Moment bequem erscheinen, kann aber schnell problematisch werden. Besser ist es, immer die expliziten Spaltennamen zu schreiben.

  • Performance: Es werden nur die benötigten Spalten geladen, was die Abfrage effizienter macht.
  • Klarheit: Du siehst sofort, welche Daten genutzt werden.
  • Stabilität: Änderungen im Schema (neue Spalten) haben keine unerwarteten Auswirkungen.

Bad Practice

SELECT * FROM users;

Good Practice

SELECT id,
       name,
       email,
       created_at
FROM users;

Auch wenn SELECT * verlockend erscheint – explizite Spaltennamen sind ein Zeichen für professionellen und wartbaren SQL-Code.

Tipp 5: Kommentare als Helfer, nicht als Krücke

Kommentare sind ein nützliches Werkzeug, um komplexe Logik oder bestimmte Entscheidungen im Code zu erklären. Wichtig ist, dass sie erklären, was und warum etwas passiert – nicht wie. Der Code selbst sollte so klar geschrieben sein, dass das „Wie“ aus dem Code ersichtlich ist.

  • Einzeilige Kommentare mit -- für kurze Erläuterungen verwenden.
  • Keine Kommentare nutzen, um unverständlichen Code zu rechtfertigen.
  • Kommentare gezielt dort einsetzen, wo die Logik für andere schwer nachvollziehbar sein könnte.

Beispiel

-- Berechnet den Nettopreis nach Abzug der Rabatte,
-- da die Business-Logik dies vorschreibt
SELECT id,
       name,
       price - discount AS net_price
FROM orders;

Richtig eingesetzte Kommentare machen deinen SQL-Code verständlicher und unterstützen dein zukünftiges Ich sowie deine Teamkollegen beim Lesen und Pflegen der Abfragen.

Tipp 6: CTEs (Common Table Expressions) für komplexe Logik

Komplexe, verschachtelte Subqueries können schnell unübersichtlich werden. CTEs – auch bekannt als WITH-Klauseln – helfen, solche Abfragen in verständliche, benannte Abschnitte zu zerlegen. Das ist wie Kapitel in einem Buch: jeder Abschnitt hat einen klaren Zweck und Namen.

  • Benutze WITH, um wiederkehrende oder komplexe Teilergebnisse zu benennen.
  • Ersetze lange verschachtelte Subqueries durch mehrere, gut lesbare CTEs.

Bad Practice

SELECT u.id, u.name, SUM(o.amount)
FROM users u
JOIN (
    SELECT user_id, amount
    FROM orders
    WHERE created_at >= '2025-01-01'
) o ON u.id = o.user_id
GROUP BY u.id, u.name;

Good Practice

WITH recent_orders AS (
    SELECT user_id, amount
    FROM orders
    WHERE created_at >= '2025-01-01'
)
SELECT u.id,
       u.name,
       SUM(ro.amount) AS total_amount
FROM users u
INNER JOIN recent_orders ro
       ON u.id = ro.user_id
GROUP BY u.id, u.name;

CTEs erhöhen die Lesbarkeit enorm, machen die Abfrage modular und erleichtern sowohl Debugging als auch Wartung.

Tipp 7: Standard-Joins explicit machen (INNER JOIN vs. ,)

Viele SQL-Anfänger verwenden die alte Komma-Syntax für Joins, zum Beispiel FROM table_a, table_b WHERE .... Das ist schwer zu lesen und leicht fehleranfällig. Besser ist, immer die explizite Join-Syntax zu nutzen: INNER JOIN, LEFT JOIN etc.

  • Explizite Joins zeigen sofort, welcher Join-Typ verwendet wird.
  • Die Bedingung für den Join steht direkt bei der Join-Klausel (ON), nicht versteckt in der WHERE-Klausel.
  • Fördert Lesbarkeit und Wartbarkeit, besonders bei mehreren Joins.

Bad Practice

SELECT u.id, u.name, o.amount
FROM users u, orders o
WHERE u.id = o.user_id;

Good Practice

SELECT u.id,
       u.name,
       o.amount
FROM users u
INNER JOIN orders o
       ON u.id = o.user_id;

Durch explizite Joins wird der SQL-Code sofort verständlicher, logischer strukturiert und weniger fehleranfällig.

Tipp 8: Logische Gruppierung mit der WHERE-Klausel

Komplexe Bedingungen in WHERE oder HAVING-Klauseln können schnell unübersichtlich werden. Durch logische Gruppierung und Klammern machst du die Absicht deines Codes sofort klar – auch wenn die Klammern nicht zwingend erforderlich wären.

  • Gruppiere zusammengehörige Bedingungen mit Klammern.
  • Verwende AND und OR bewusst, um logische Prioritäten sichtbar zu machen.
  • Erleichtert das Debugging und verhindert unerwartete Ergebnisse.

Bad Practice

WHERE status = 'active' AND department = 'IT' OR is_admin = TRUE

Good Practice

WHERE (status = 'active' AND department = 'IT')
   OR (is_admin = TRUE)

Klare Gruppierungen in Bedingungen sorgen dafür, dass die Logik sofort nachvollziehbar ist und du zukünftige Fehler vermeidest.

Tipp 9: Konsistente Reihenfolge der Klauseln

Eine einheitliche Reihenfolge der SQL-Klauseln macht Abfragen vorhersehbar und leichter lesbar. Dein Auge gewöhnt sich an ein Muster, was insbesondere bei langen Abfragen enorme Vorteile bringt.

  • Häufig genutzte, logische Reihenfolge: SELECT → FROM → [JOINs] → WHERE → GROUP BY → HAVING → ORDER BY
  • Immer gleiche Reihenfolge anwenden, auch wenn einige Klauseln leer bleiben.
  • Fördert Lesbarkeit und erleichtert Teamarbeit.

Beispiel

SELECT u.id,
       u.name,
       SUM(o.amount) AS total_amount
FROM users u
INNER JOIN orders o
       ON u.id = o.user_id
WHERE u.status = 'active'
GROUP BY u.id, u.name
HAVING SUM(o.amount) > 100
ORDER BY total_amount DESC;

Wenn alle Abfragen einem konsistenten Muster folgen, sparst du Zeit beim Lesen und Verstehen, selbst nach Monaten.

Tipp 10: Vermeide übermäßig cleveren Code

Exotische Funktionen, verschachtelte CASE-Statements oder undokumentierte Tricks mögen kurzfristig „smart“ wirken. Langfristig sind sie jedoch eine Falle – für dein zukünftiges Ich und für deine Kollegen. Klarheit sollte immer über Cleverness stehen.

  • Bevorzuge verständliche Logik statt extrem verschachtelter Abfragen.
  • Dokumentiere ungewöhnliche Entscheidungen immer mit Kommentaren.
  • Denke daran: wartbarer Code ist wertvoller als beeindruckender Code.

Bad Practice

SELECT id,
       CASE WHEN status = 'active' THEN
            CASE WHEN last_login > NOW() - INTERVAL '30 days' THEN 'recent'
                 ELSE 'inactive' END
       ELSE 'inactive' END AS user_status
FROM users;

Good Practice

-- Klassifiziert Benutzer als 'recent' oder 'inactive' basierend auf Status und letztem Login
SELECT id,
       CASE 
           WHEN status = 'active' AND last_login > NOW() - INTERVAL '30 days' THEN 'recent'
           ELSE 'inactive'
       END AS user_status
FROM users;

Weniger verschachtelte und klar kommentierte Logik macht Abfragen leichter verständlich, wartbar und sicherer.

Before & After: Das große Ganze

Jetzt fassen wir alle Tipps zusammen und zeigen den Unterschied zwischen einer unlesbaren Abfrage und derselben Abfrage, die alle 10 Regeln beachtet. So siehst du auf einen Blick, wie viel klarer dein SQL-Code werden kann.

Unlesbare Abfrage (Before)

SELECT * FROM users u, orders o WHERE u.id=o.user_id AND u.status='active' AND o.amount>100 ORDER BY o.amount DESC;

Lesbare Abfrage nach allen 10 Tipps (After)

-- Holt alle aktiven Benutzer mit Bestellungen über 100, sortiert nach Bestellwert
WITH recent_orders AS (
    SELECT user_id,
           amount
    FROM orders
    WHERE amount > 100
)
SELECT u.id,
       u.name,
       SUM(ro.amount) AS total_amount
FROM users u
INNER JOIN recent_orders ro
       ON u.id = ro.user_id
WHERE u.status = 'active'
GROUP BY u.id, u.name
ORDER BY total_amount DESC;

Durch konsistente Formatierung, explizite Joins, CTEs, Kommentare und klare Klausel-Reihenfolge wird die Abfrage deutlich verständlicher und leichter wartbar.

Fazit: Lesbarkeit ist eine Frage der Disziplin

Lesbarer SQL-Code ist kein Luxus – er ist respektvoll gegenüber deinen Kollegen und deinem zukünftigen Ich. Mit konsistenter Formatierung, klaren Aliasen, Kommentaren, CTEs und einer logischen Struktur wird jede Abfrage verständlicher, weniger fehleranfällig und einfacher zu warten.