SQL Interview Prep · Lektion

Verschachtelte Abfragen in CTEs umstrukturieren

Ein Muster fürs Live-Interview: Eine unleserliche verschachtelte Abfrage in schrittweise aufgebaute CTEs umwandeln

Verschachtelte Abfragen in CTEs umstrukturieren ist eine kostenlose SQL Interview Prep-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des SQL Interview Prep-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der SQL Interview Prep-Kurs umfasst insgesamt 4 Lektionen.

Das Refactoring im Live-Interview

Eine typische Aufgabe für ein Vorstellungsgespräch auf mittlerem Niveau lautet: Hier ist eine Abfrage, machen Sie sie lesbar. Die interviewende Person gibt Ihnen ein tief verschachteltes SELECT und beobachtet, wie Sie es zerlegen. Die Verschachtelung in eine Abfolge benannter CTEs umzuwandeln, ist die sauberste Lösung.

Diese Lektion zeigt Ihnen die genauen Schritte, damit Sie sie am Whiteboard ruhig durchführen können.

Mit der innersten Abfrage beginnen

Verschachtelte Unterabfragen werden gedanklich von innen nach außen ausgeführt. Lesen Sie die Abfrage daher ebenfalls von innen nach außen: Suchen Sie zuerst das tiefste SELECT in Klammern; es bildet die erste Stufe Ihrer Pipeline.

Geben Sie ihm einen aussagekräftigen Namen und übernehmen Sie es in eine CTE. Alles, was auf diesen inneren Block verwiesen hat, verweist nun stattdessen auf den Namen der CTE.

SELECT *
FROM (
    SELECT customer_id, SUM(amount) AS total
    FROM orders
    GROUP BY customer_id
) t
WHERE t.total > 1000;

Eine Ebene in eine CTE übernehmen

Nehmen Sie die innerste abgeleitete Tabelle und machen Sie daraus eine CTE. Die äußere Abfrage bleibt gleich, außer dass sie nun aus der benannten CTE auswählt.

Dieser eine Schritt entfernt bereits eine Ebene der gedanklichen Verschachtelung und gibt dem Schritt einen aussagekräftigen Namen.

WITH spend AS (
    SELECT customer_id, SUM(amount) AS total
    FROM orders
    GROUP BY customer_id
)
SELECT *
FROM spend
WHERE total > 1000;

Ein wirklich verschachteltes Beispiel

Hier ist ein schwierigeres Beispiel für ein Refactoring: zwei Verschachtelungsebenen plus ein Filter nach Art einer korrelierten Abfrage. Das Ziel ist der durchschnittliche Bestellwert unter den Kundinnen und Kunden in der höchsten Ausgabenklasse.

Die Abfrage ist korrekt, aber schwer zu lesen. Wir werden sie Schritt für Schritt auseinandernehmen.

SELECT AVG(o.amount) AS avg_order
FROM orders o
WHERE o.customer_id IN (
    SELECT customer_id
    FROM (
        SELECT customer_id, SUM(amount) AS total
        FROM orders
        GROUP BY customer_id
    ) s
    WHERE s.total > 1000
);

Die erste Stufe benennen

Der tiefste Block berechnet den Gesamtumsatz pro Kundin oder Kunde. Übernehmen Sie ihn in eine CTE namens spend. Nun filtert die mittlere Ebene einfach diese CTE.

Beachten Sie, wie jede Herauslösung die Verschachtelungstiefe um eins verringert und einen selbstdokumentierenden Namen hinzufügt.

WITH spend AS (
    SELECT customer_id, SUM(amount) AS total
    FROM orders
    GROUP BY customer_id
)
SELECT AVG(o.amount) AS avg_order
FROM orders o
WHERE o.customer_id IN (
    SELECT customer_id FROM spend WHERE total > 1000
);

Die zweite Stufe benennen

Extrahieren Sie den Filter auf spend in eine eigene CTE namens big_spenders. Die verbleibende Hauptabfrage wird zu einer flachen Verknüpfung oder einer Mitgliedschaftsprüfung gegen eine klar benannte Menge.

Jede Stufe hat nun genau eine Aufgabe – ein Kennzeichen von sauberem SQL.

WITH spend AS (
    SELECT customer_id, SUM(amount) AS total
    FROM orders GROUP BY customer_id
),
big_spenders AS (
    SELECT customer_id FROM spend WHERE total > 1000
)
SELECT AVG(o.amount) AS avg_order
FROM orders o
JOIN big_spenders b ON b.customer_id = o.customer_id;

Beim Refactoring die Semantik bewahren

Die wichtigste Regel: Ein Refactoring darf die Ergebnisse nicht verändern. Achten Sie auf Fallen, die die Ausgabe unbemerkt verändern:

Der Wechsel von IN zu einem JOIN kann doppelte Zeilen erzeugen, wenn die rechte Seite nicht eindeutig ist.
NOT IN mit NULL-Werten verhält sich anders als NOT EXISTS.
Die Granularität der Aggregation muss gleich bleiben.

Benennen Sie diese Risiken ausdrücklich, um Ihre Sorgfalt zu zeigen.

Das Refactoring überprüfen

Wie weisen Sie nach, dass das Refactoring semantisch korrekt ist? Erwähnen Sie, dass Sie beide Versionen ausführen und die Zeilenanzahl sowie eine Prüfsumme vergleichen oder die Ergebnismengen anhand einer Stichprobe vergleichen würden.

In einem Interview zeigt bereits die Aussage Ich würde die Anzahlen und einige Stichprobenzeilen vergleichen technisches Verantwortungsbewusstsein, das über das bloße Umschreiben der Syntax hinausgeht.

SELECT COUNT(*), SUM(amount)
FROM orders
WHERE customer_id IN (SELECT customer_id FROM big_spenders);

Wann Sie NICHT refactoren sollten

Refactoring ist nicht immer eine Verbesserung. Eine einzelne, flache Unterabfrage ist möglicherweise klarer, wenn Sie sie unverändert lassen, und auch die Aufteilung in viele winzige CTEs kann die Lesbarkeit beeinträchtigen.

Urteilen Sie mit Augenmaß: Refactoren Sie, wenn Verschachtelungen die Absicht verschleiern oder Logik wiederverwendet wird. Sagen Sie dem Interviewer, dass Sie aufhören würden, sobald die Abfrage von oben nach unten wie eine Folge klar abgegrenzter, benannter Schritte lesbar ist.

Die Refactoring-Checkliste

Eine Methode, die Sie immer wieder anwenden können:

Lesen Sie von innen nach außen, um die tiefste Unterabfrage zu finden.
Heben Sie sie in eine benannte CTE.
Arbeiten Sie sich auf diese Weise Schicht für Schicht nach außen vor.
Benennen Sie jede Stufe danach, was sie erzeugt.
Bestätigen Sie, dass die Ergebnisse unverändert sind (achten Sie auf Fallen bei IN/JOIN und NULL).

So wird aus einer beängstigend verschachtelten Abfrage eine ruhige, schrittweise Überarbeitung.

Ihr Refactoring erklären

Sprechen Sie während der Arbeit mit: Der innerste Block berechnet die Ausgaben pro Kunde, daher nenne ich ihn spend. Die nächste Ebene filtert Kunden mit hohen Ausgaben. Dann bildet die äußere Abfrage den Durchschnitt ihrer Bestellbeträge.

Interviewer bewerten die Kommunikation ebenso stark wie die Korrektheit. Ein erklärtes Refactoring Schritt für Schritt zeigt genau die Praxiserfahrung auf mittlerem Niveau, die sie erwarten.

Kurzer Test

Identifizieren Sie den richtigen ersten Schritt beim Refactoring einer tief verschachtelten Abfrage in CTEs.

Rückblick: Refactoring in CTEs

Sie haben ein ruhiges, wiederholbares Refactoring gelernt: Lesen Sie von innen nach außen, heben Sie die tiefste Unterabfrage in eine benannte CTE und arbeiten Sie sich Schicht für Schicht nach außen vor.

Benennen Sie jede Stufe danach, was sie erzeugt.
Bewahren Sie die Semantik; achten Sie auf Duplikate bei IN gegenüber JOIN und auf NULL-Fallen.
Validieren Sie durch den Vergleich von Anzahlen und Stichprobenzeilen.
Teilen Sie die Abfrage nicht übermäßig auf; hören Sie auf, sobald sie wie klare, benannte Schritte lesbar ist.

Damit ist der CTE-Kurs abgeschlossen; Sie können nun in einem Live-Interview selbstbewusst refactoren.

Häufig gestellte Fragen

Ist die Lektion „Verschachtelte Abfragen in CTEs umstrukturieren“ kostenlos?

Ja — der vollständige Text von „Verschachtelte Abfragen in CTEs umstrukturieren“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des SQL Interview Prep-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der SQL Interview Prep-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Verschachtelte Abfragen in CTEs umstrukturieren“?

Ein Muster fürs Live-Interview: Eine unleserliche verschachtelte Abfrage in schrittweise aufgebaute CTEs umwandeln Du übst SQL Interview Prep mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um SQL Interview Prep zu starten?

Keine Vorkenntnisse erforderlich. SQL Interview Prep auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „Verschachtelte Abfragen in CTEs umstrukturieren“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser SQL Interview Prep-Lektion Code schreiben und ausführen?

Ja. Jede SQL Interview Prep-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

Ihre erste CTE schreiben
Mehrere CTEs verketten
CTE oder Unterabfrage oder temporäre Tabelle
Verschachtelte Abfragen in CTEs umstrukturieren

← Zurück zu SQL Interview Prep