CTE w SQL - Jak uporządkować zapytania i analizę danych?

CTE, czyli common table expression, to nazwany wynik pośredni w SQL, który pomaga rozbić złożone zapytanie na czytelne kroki bez tworzenia trwałej tabeli. W praktyce jest to jedno z najwygodniejszych narzędzi w analizie danych, raportowaniu i budowaniu zapytań, które ktoś poza autorem ma jeszcze zrozumieć po tygodniu albo po kwartale. Poniżej pokazuję, jak działa to w SQL, kiedy naprawdę upraszcza pracę i gdzie jego użycie przestaje mieć sens.

Czym jest CTE i dlaczego tak dobrze porządkuje SQL

Ja traktuję CTE jak roboczy etap myślenia zapisany bezpośrednio w zapytaniu. Najpierw opisuję fragment problemu, nadaję mu nazwę, a dopiero potem wykorzystuję go w końcowym SELECT-cie. Dzięki temu zamiast jednego długiego bloku zagnieżdżonych podzapytań dostaję kilka krótszych kroków, które łatwiej przeczytać, poprawić i omówić z zespołem.

Najważniejsza rzecz: CTE nie tworzy trwałego obiektu w bazie. Istnieje tylko w zakresie jednego polecenia SQL, więc jest dobre do logiki przetwarzania, ale nie do przechowywania danych. To odróżnia je od tabeli tymczasowej i od widoku, które pełnią inną rolę.

W praktyce CTE jest szczególnie wygodne, gdy raport ma kilka etapów: najpierw agregację, potem filtrację najlepszych wyników, a na końcu dołączenie szczegółów. Wtedy kod przestaje wyglądać jak zagadka i zaczyna przypominać instrukcję krok po kroku. To dobry moment, żeby zobaczyć, jak taka konstrukcja wygląda od środka.

Jak wygląda składnia i jak czytać zapytanie krok po kroku

Składnia jest krótka, ale warto czytać ją warstwowo. Najpierw definiujesz nazwany wynik, później używasz go w głównym zapytaniu. Jeśli jest kilka CTE, mogą one zależeć od siebie w tej samej klauzuli, o ile zachowasz właściwą kolejność.

WITH regional_sales AS (
    SELECT region, SUM(amount) AS total_sales
    FROM orders
    GROUP BY region
),
top_regions AS (
    SELECT region
    FROM regional_sales
    WHERE total_sales > (SELECT SUM(total_sales) / 10 FROM regional_sales)
)
SELECT region,
       product,
       SUM(quantity) AS product_units,
       SUM(amount) AS product_sales
FROM orders
WHERE region IN (SELECT region FROM top_regions)
GROUP BY region, product;

Ten przykład dobrze pokazuje sens CTE: najpierw liczę sprzedaż według regionów, potem wybieram najlepsze regiony, a na końcu buduję raport produktowy tylko dla wybranego fragmentu danych. Bez CTE dałoby się to napisać, ale kod byłby bardziej poskręcany i trudniejszy do modyfikacji. Kiedy człowiek wraca do takiego zapytania po czasie, ta różnica naprawdę ma znaczenie.

Jeżeli używasz kilku CTE obok siebie, pamiętaj o kolejności i o tym, że późniejszy krok może korzystać z wcześniejszego, ale nie odwrotnie. To prowadzi wprost do pytania, kiedy taki zapis faktycznie daje przewagę nad zwykłym podzapytaniem.

Gdzie CTE daje największą przewagę w analizie danych

W projektach analitycznych CTE najczęściej wygrywa tam, gdzie dane przechodzą przez kilka logicznych filtrów. Dobrze sprawdza się przy przygotowaniu zestawień sprzedaży, segmentacji klientów, czyszczeniu danych po imporcie albo wyliczaniu metryk pośrednich, które mają sens tylko w jednym raporcie.

• Agregacje etapowe - najpierw sumujesz, potem filtrujesz najlepsze grupy, a dopiero później łączysz wynik z inną tabelą.
• Przygotowanie danych do raportu - gdy chcesz pokazać jeden logiczny wynik biznesowy, a nie surowy techniczny join.
• Łatwiejszy review kodu - każdy CTE można przeczytać jak osobny akapit, a nie jak ścianę SQL.
• Szybsze debugowanie - możesz sprawdzać kolejne kroki logiczne zamiast zgadywać, który fragment zagnieżdżenia psuje wynik.

Ja zwykle wybieram CTE wtedy, gdy zależy mi bardziej na czytelności niż na skróceniu liczby linijek. To nie jest narzędzie do popisów składniowych, tylko do porządkowania myślenia. Jeśli to zapytanie ma być potem utrzymywane przez kogoś z zespołu, taki wybór zwykle się zwraca. A skoro już mowa o wyborze narzędzia, warto postawić CTE obok najczęstszych alternatyw.

CTE, podzapytanie, tabela tymczasowa i widok nie robią tego samego

Najwięcej błędów widzę wtedy, gdy ktoś traktuje CTE jak uniwersalny zamiennik wszystkiego. To wygodna konstrukcja, ale nie zawsze najlepsza. Poniższe porównanie porządkuje różnice, które w praktyce robią największą robotę.

W praktyce CTE wygrywa, gdy potrzebujesz jednego przejrzystego przepływu danych. Tabela tymczasowa lepsza jest wtedy, gdy ten sam wynik odwołuje się kilka razy albo chcesz go dodatkowo zoptymalizować. Widok z kolei ma sens, gdy chcesz utrwalić definicję logiczną, a nie jednorazowy krok analityczny. To prowadzi do ważnego wyjątku: rekurencji, bo tam CTE robi coś, czego inne konstrukcje nie rozwiązują tak elegancko.

Rekurencyjne CTE do hierarchii, drzew i ścieżek

Rekurencyjne CTE przydaje się wtedy, gdy dane są powiązane z samymi sobą: struktura organizacyjna, drzewo kategorii, lista zależności, ścieżka BOM albo graf połączeń. W takich przypadkach pierwsza część zapytania ustawia punkt startowy, a druga iteracyjnie dokłada kolejne poziomy. To właśnie ta cecha sprawia, że CTE jest tak mocne w zadaniach analitycznych z układem nadrzędny-podrzędny.

WITH RECURSIVE org_chart AS (
    SELECT employee_id, manager_id, full_name, 0 AS level
    FROM employees
    WHERE manager_id IS NULL

    UNION ALL

    SELECT e.employee_id, e.manager_id, e.full_name, oc.level + 1
    FROM employees e
    JOIN org_chart oc ON e.manager_id = oc.employee_id
)
SELECT employee_id, full_name, level
FROM org_chart
ORDER BY level, full_name;

W tym przykładzie pierwszy SELECT buduje punkt startowy, a drugi rozszerza wynik o kolejne osoby podlegające menedżerom. Jeśli pracujesz w SQL Server, składnia jest bardzo podobna, ale bez słowa RECURSIVE; w PostgreSQL ten zapis jest standardowy. Najważniejsze jest jednak nie samo słowo kluczowe, tylko warunek zakończenia. Bez niego zapytanie może zacząć zapętlać się bez końca.

Jeśli masz hierarchię danych, rekurencyjne CTE często pozwala uniknąć kursorów, procedur i ręcznego klejenia poziomów. To właśnie tu widać największą różnicę między prostym SQL-em a zapytaniem, które realnie rozwiązuje problem biznesowy. Ale ta wygoda ma swoje granice i warto je znać, zanim zacznie się nadużywać tej konstrukcji.

Najczęstsze błędy i ograniczenia, które widzę w praktyce

Największy błąd brzmi banalnie: zakładanie, że CTE zawsze poprawia wydajność. Nie poprawia. Poprawia czytelność, a wydajność zależy od tego, jak silnik zbuduje plan wykonania, jak duży jest zbiór danych i ile razy wynik pośredni jest używany.

• Traktowanie CTE jak bufora danych - to nie jest magazyn, tylko krok logiczny.
• Powtarzanie kosztownej logiki kilka razy - jeśli wynik jest ciężki i używasz go wielokrotnie, tabela tymczasowa bywa sensowniejsza.
• Brak warunku zakończenia w rekurencji - to prosta droga do nieskończonego zapętlenia.
• Zbyt ogólne nazwy - nazwa typu cte1 albo temp_data nie mówi nic o zamiarze.
• Ukrywanie modelu danych - CTE może poprawić SQL, ale nie naprawi słabej struktury tabel.

W SQL Server warto pamiętać, że wynik CTE nie jest materializowany jako gotowa tabela, więc przy wielokrotnych odwołaniach koszt może wrócić. W PostgreSQL część zapytań z WITH potrafi zostać wbudowana w większy plan, więc zachowanie bywa inne niż w starszych wersjach baz, gdzie wiele osób zakładało zawsze ten sam efekt. Dlatego patrzę na plan wykonania, a nie tylko na składnię.

Jest jeszcze jedna pułapka: nie zakładaj, że porządek w CTE zastępuje ORDER BY w zapytaniu końcowym. Jeśli chcesz pewnego układu wyników, sortowanie musi być tam, gdzie zwracasz finalny rezultat. W przeciwnym razie logika analityczna może być poprawna, ale prezentacja danych już nie.

Jak pisać CTE, żeby kod był naprawdę czytelny

Najlepiej działa zasada jednego kroku na jeden CTE. Jeśli jeden blok robi agregację, kolejny filtruje, a trzeci dołącza szczegóły, kod pozostaje czytelny. Gdy zaczynasz upychać w jednym CTE pół logiki biznesowej, traci on swój największy atut.

• Nazwij wynik, nie operację - lepiej top_regions niż calc_step_2.
• Wybieraj tylko potrzebne kolumny - w analizie danych nadmiar pól szybko mąci obraz.
• Trzymaj CTE blisko głównego zapytania - im dalej od finalnego wyniku, tym łatwiej zgubić sens.
• Nie mnoż zagnieżdżeń bez potrzeby - jeśli potrzebujesz pięciu warstw, to znak, że warto przeprojektować logikę.
• Myśl o CTE jak o zdaniu w argumentacji - ma prowadzić do wniosku, a nie być osobnym eseistycznym bytem.

W code review zwykle pytam jedno: czy ten CTE pomaga zrozumieć zapytanie po 30 sekundach czytania? Jeśli odpowiedź brzmi nie, to znaczy, że konstrukcja zaczyna być ozdobą zamiast narzędzia. Dobrze napisane CTE nie przyciąga uwagi, tylko porządkuje tok myślenia. A to jest dokładnie ta jakość, której szuka się w dojrzałej pracy z danymi.

Kiedy CTE zostaje w kodzie, a kiedy warto wybrać inne rozwiązanie

CTE zostawiam wtedy, gdy ma być przejrzystym, jednorazowym etapem logiki SQL. To dobry wybór do raportów, transformacji, filtrów biznesowych i rekurencji. W takich scenariuszach daje najlepszy stosunek prostoty do wartości.

Zmieniłbym narzędzie, gdy ten sam wynik ma być użyty kilka razy, gdy potrzebujesz indeksów po drodze albo gdy zapytanie zaczyna udawać mini-procedurę. Wtedy lepiej spojrzeć na tabelę tymczasową, materializowany wynik albo przebudować sam model danych. W praktyce najwięcej zysku daje nie sama technika, ale świadomy wybór miejsca, w którym ona ma sens.

Jeśli miałbym zostawić jedną zasadę, byłaby prosta: CTE ma pomagać myśleć etapami, a nie maskować złożoność. Gdy pełni tę rolę, jest jednym z najbardziej użytecznych narzędzi w pracy analityka i osoby piszącej SQL. Gdy przestaje ją pełnić, lepiej od razu sięgnąć po inną konstrukcję niż sztucznie ratować zapytanie kolejną warstwą.