sql/debug
QUERY · aus sql-meistern Kapitel 4 (AP-Niveau) 7 Zeilen · 3-fach verschachtelt · nicht-korreliert
SELECT vorname, nachname FROM kunden WHERE kunden_id IN ( SELECT kunden_id FROM bestellungen WHERE bestell_id IN ( SELECT bestell_id FROM bestellpositionen WHERE einzelpreis > 500 ) )
FROM15 Zeilen
WHERE IN3 Ebenen
SELECT—

Schritt 2 · WHERE kunden_id IN (...) · nicht-korreliert, 3 Ebenen

Auswertung: innen → außen
Bei nicht-korrelierten Subqueries wertet SQL von innen nach außen aus. Jede Ebene erzeugt eine Menge, die zur Filter-Bedingung für die nächsthöhere Ebene wird. Anders als bei korrelierten Subqueries läuft jede Ebene nur einmal, unabhängig von der äußeren Tabelle.
3
Innerste Ebene · läuft als erste
Quelle: bestellpositionen
→ liefert Menge von bestell_id
SELECT bestell_id FROM bestellpositionen WHERE einzelpreis > 500
Ergebnismenge 4 bestell_ids
5 7 12 18
↓ wird als IN-Menge in Ebene 2 eingesetzt
2
Mittlere Ebene · läuft mit eingesetzter Menge
Quelle: bestellungen
→ liefert Menge von kunden_id
SELECT kunden_id FROM bestellungen WHERE bestell_id IN { 5, 7, 12, 18 }
Ergebnismenge 5 kunden_ids
2 3 7 11 14
↓ wird als IN-Menge in Ebene 1 eingesetzt
1
Äußerste Ebene · liefert das Endergebnis
Quelle: kunden
→ liefert vorname, nachname
SELECT vorname, nachname FROM kunden WHERE kunden_id IN { 2, 3, 7, 11, 14 }
Endergebnis 5 Zeilen
vornamenachname
AnnaSchmidt
LenaWeber
FelixBauer
SophieKlein
JonasWagner
Schüler-Trugschluss: "Ich lese die Query von oben nach unten." Falsch — SQL wertet bei nicht-korrelierten Subqueries innen-zuerst aus. Die richtige Lese-Reihenfolge ist 3 → 2 → 1, das spiegelt das Tool wider.

Stress-Test: was passiert bei höherer Komplexität?

✓ 3-fach JOIN (sql-meistern Kapitel 3)

Step-Rail bekommt 8 Pills (FROM, JOIN1, JOIN2, JOIN3, GROUP BY, HAVING, SELECT, ORDER BY) — passt mit horizontalem Scroll. Jeder JOIN-Step bekommt eigene Row-Expansion-Viz.

✓ Korrelierte Scalar-Subquery

z.B. WHERE preis > (SELECT AVG(preis) ... WHERE kategorie_id = p.kategorie_id) — gleiche Iterations-Viz wie EXISTS, aber Verdikt zeigt Wert-Vergleich statt TRUE/FALSE.

✓ Subquery in FROM (Derived Table)

z.B. SELECT COUNT(*) FROM (...UNION...) — die innere Query bekommt einen eigenen "Sub-Pipeline-Step", der vor dem Haupt-FROM ausgewertet wird. Inner-Pipeline ist eigene Mini-Sequenz.

⚠ Sehr große Zwischenergebnisse

Nach 3-fach JOIN auf TECHNOVA-Schema: oft 200+ Zeilen. Pagination zwingend (zeige 10 / zeige 50 / zeige alles). Visualisierung der Row-Multiplikation funktioniert dann nur noch über Samples ("3 von 12 Müller-Zeilen gezeigt").

⚠ Subquery im SELECT (Scalar)

z.B. SELECT name, (SELECT COUNT(*) FROM ... WHERE ...) AS anzahl — läuft pro äußere Zeile, ähnlich wie korrelierte WHERE-Subquery. Braucht eigene Viz: Tabelle mit "running" Subquery-Spalte, die pro Zeile aufgedeckt wird.

⚠ 4+ Ebenen Schachtelung

Theoretisch unendlich, in der AP praktisch max. 3. Bei 4+ wird die Vertikal-Stack-Visualisierung schlauchig — Lösung: Inner-Levels collapsible (Default: nur 1+2 expanded, tiefere als "Klick zum Aufklappen").

Bewerte Non-Korrelations-Viz + Stress-Test

APasst — auch der Skalierungs-Pragmatismus
Bottom-up-Pipeline mit nummerierten Ebenen (3 → 2 → 1) und farbcodierten Sets macht die Auswertungsreihenfolge sichtbar. Die genannten Grenzen bei großen Tabellen / tiefer Schachtelung / Subquery im SELECT akzeptieren wir als MVP-Pragmatismus.

BViz passt, aber Skalierungs-Probleme sind ein Showstopper
Wenn nach 3-fach JOIN regelmäßig 200+ Zeilen entstehen und die Row-Multiplikations-Viz nur noch Samples zeigt, verliert das Tool seinen pädagogischen Mehrwert genau dort, wo Schüler ihn brauchen. Müssen wir tiefer durchdenken.
C3-Ebenen-Viz noch nicht ganz klar — andere Metapher
Vertikale Stack-Boxes funktionieren bei 3 Ebenen, werden bei 4+ unhandlich. Alternative: Tree-View seitlich, oder eingerückte Ebenen mit Schachtelungs-Tiefe als horizontale Einrückung.
DEtwas Anderes — im Terminal
Spezifisches Feedback im Chat.