Zum Inhalt springen
SemaTrain

SQL-WISSEN · Abfragestruktur

Subqueries, CTE, CASE und EXISTS

Wie Unterabfragen, Common Table Expressions, EXISTS und CASE komplexere SQL-Abfragen strukturieren und unterschiedliche fachliche Fragen ausdrücken.

Subquery und EXISTS

Eine Subquery ist eine Abfrage innerhalb eines größeren SQL-Ausdrucks. Sie kann beispielsweise Werte für einen Vergleich liefern oder als Teil einer Existenzprüfung dienen.

EXISTS beantwortet die Frage, ob die zugehörige Subquery mindestens eine Zeile liefert. Dabei steht die Existenz passender Zeilen im Vordergrund, nicht eine einzelne zurückgegebene Kennzahl.

Existenzprüfung
SELECT k.id, k.name
FROM kunde AS k
WHERE EXISTS (
  SELECT 1
  FROM bestellung AS b
  WHERE b.kunde_id = k.id
);

CTE mit WITH

Eine Common Table Expression gibt einem Zwischenergebnis innerhalb eines einzelnen SQL-Statements einen Namen. Gewöhnliche CTEs können dadurch verschachtelte Abfragen lesbarer strukturieren.

Rekursive CTEs und Fragen der Materialisierung oder Optimierung besitzen zusätzliche produktbezogene Regeln. Deshalb wird aus der Verwendung von WITH keine pauschale Performanceaussage abgeleitet.

Benanntes Zwischenergebnis
WITH umsatz AS (
  SELECT kunde_id, SUM(betrag) AS gesamt
  FROM bestellung
  GROUP BY kunde_id
)
SELECT kunde_id, gesamt
FROM umsatz
WHERE gesamt >= 1000;

CASE als bedingter Ausdruck

CASE ist ein Ausdruck für bedingte Ergebniswerte. Er kann beispielsweise Kategorien bilden, ohne dafür die Zeilenmenge selbst zu verändern.

CTE, Subquery und CASE lösen unterschiedliche Strukturierungsprobleme: CTE und Subquery erzeugen beziehungsweise kapseln Abfrageergebnisse; CASE berechnet einen Wert abhängig von Bedingungen.

Klassifikation mit CASE
SELECT id,
       CASE
         WHEN betrag >= 1000 THEN 'hoch'
         WHEN betrag >= 100 THEN 'mittel'
         ELSE 'niedrig'
       END AS klasse
FROM bestellung;

Kritisch unterscheiden

  • EXISTS prüft die Existenz passender Zeilen. Eine skalare Subquery wird in einem Wertkontext verwendet; bei mehreren Ergebniszeilen unterscheiden sich die Produkte: SQLite verwendet die erste Ergebniszeile, PostgreSQL 18 und MySQL 8.4 melden in einem skalaren Kontext einen Fehler.
  • Eine CTE gilt nur im Gültigkeitsbereich des zugehörigen Statements und ist nicht dasselbe wie eine dauerhaft definierte View.
  • CASE ist ein Ausdruck und nicht mit prozeduraler Kontrollflusslogik eines Stored-Program-Kontexts gleichzusetzen.

Typische Fehler und Missverständnisse

  • Eine CTE automatisch als Performanceoptimierung zu verstehen.
  • EXISTS und IN ohne Beachtung der fachlichen Frage und möglicher NULL-Semantik austauschbar zu behandeln.
  • CASE zu verwenden, obwohl eigentlich Zeilen gefiltert statt Ergebniswerte klassifiziert werden sollen.

Praxisfall

Kunden mit Aktivität segmentieren

Kunden sollen nur erscheinen, wenn Bestellungen existieren. Zusätzlich soll ihr Gesamtumsatz in Klassen eingeteilt werden.

  • Welche Teilfrage eignet sich für EXISTS?
  • Welches Zwischenergebnis könnte als CTE lesbarer werden?
  • Welche Klassifikation gehört in CASE?

Selbsttest

Verständnis prüfen

1. Wofür ist EXISTS besonders geeignet?

Antwortmöglichkeiten zu Frage 1
Antwort und Begründung anzeigen

EXISTS beschreibt eine Existenzprüfung auf dem Ergebnis einer Subquery.

2. Was unterscheidet eine gewöhnliche CTE von einer View?

Antwortmöglichkeiten zu Frage 2
Antwort und Begründung anzeigen

Die gewöhnliche CTE besitzt Statement-Scope. Eine View wird als Datenbankobjekt definiert und kann später erneut referenziert werden.

Transfer

Auf die eigene Praxis übertragen

Nehmen Sie eine verschachtelte Abfrage aus einem Projekt. Markieren Sie Existenzprüfung, Zwischenergebnis und bedingte Ergebnislogik getrennt und entscheiden Sie, ob Subquery, CTE, EXISTS oder CASE die jeweilige Absicht am klarsten ausdrückt.

Weiterlernen

Verknüpfungen

Quellen, Prüfstand und Grenzen

Fachliche Nachvollziehbarkeit

Quellen geprüft
2026-09-27
Versionsrahmen
Gemeinsamer SQL-Kern mit explizit gekennzeichneten Varianten für SQLite 3.53.4, PostgreSQL 18 und MySQL 8.4 LTS.
Aussagebereich
Subqueries, EXISTS, gewöhnliche CTEs und CASE werden als gemeinsamer SQL-Kern erläutert. Rekursion, Materialisierung, Optimierung und einzelne Detailregeln bleiben produktbezogen.
Originalität
Faktenbasis aus Primärquellen; Einordnung, Struktur, Beispiele, Selbsttests und Transfer sind eigenständige SemaTrain-Inhalte.

Grenzen

  • Rekursion, CTE-Materialisierung, Optimizerverhalten und einzelne Ausdrucksdetails sind produktabhängig.
  • Produktspezifische Syntax und Verhalten können sich zwischen SQLite, PostgreSQL und MySQL unterscheiden.
  • Versionsabhängige Aussagen gelten für den im Quellenbereich ausgewiesenen Prüfstand.

Primärquellen

Projekt-Primärdokumentation

SQLite SELECT

SQLite

Version: SQLite 3.53.4

Bezug: SELECT, Subqueries sowie IN- und EXISTS-Kontext.

Projekt-Primärdokumentation

SQLite WITH Clause

SQLite

Version: SQLite 3.53.4

Bezug: WITH, gewöhnliche und rekursive Common Table Expressions sowie SQLite-spezifische Hinweise.

Projekt-Primärdokumentation

SQLite SQL Language Expressions

SQLite

Version: SQLite 3.53.4

Bezug: CASE-Ausdruck, skalare Subquery-Auswertung einschließlich Erstzeilenverhalten, Ausdruckssemantik und NULL-bezogene Auswertungsregeln.

Projekt-Primärdokumentation

PostgreSQL 18 WITH Queries

PostgreSQL

Version: PostgreSQL 18

Bezug: WITH, Common Table Expressions, Rekursion und PostgreSQL-spezifische Ausführungsaspekte.

Projekt-Primärdokumentation

PostgreSQL 18 Value Expressions

PostgreSQL

Version: PostgreSQL 18

Bezug: Skalare Subqueries: ein Wertkontext, NULL bei keiner Ergebniszeile und Fehler bei mehr als einer Ergebniszeile.

Hersteller-Primärdokumentation

MySQL 8.4 Scalar Subqueries

MySQL

Version: MySQL 8.4 LTS

Bezug: Skalare Subqueries als Einzelwert; NULL bei leerem Ergebnis und Fehlerkontext bei mehreren Ergebniszeilen.

Hersteller-Primärdokumentation

MySQL 8.4 Subqueries

MySQL

Version: MySQL 8.4 LTS

Bezug: MySQL-Subquery-Syntax und -Semantik einschließlich EXISTS.