GROUP BY w SQL - Jak grupować dane i unikać błędów?

Grupowanie w SQL przydaje się wtedy, gdy pojedyncze wiersze trzeba zamienić w sensowny raport: liczbę zamówień, średnią wartość koszyka, sprzedaż per region albo liczbę aktywnych użytkowników per miesiąc. W praktyce chodzi o to, żeby z danych szczegółowych zrobić wynik zbiorczy bez ręcznego liczenia po stronie aplikacji. Właśnie tu najlepiej widać, jak działa `SELECT` z `GROUP BY` i gdzie najłatwiej popełnić błąd.

Jak działa grupowanie i co właściwie zwraca

Najprościej myśleć o `GROUP BY` jak o sortowaniu danych do pudełek według wspólnej cechy. Jeśli grupujesz po `department`, to wszystkie wiersze z tym samym działem trafiają do jednego pudełka, a potem SQL liczy dla niego jedną wartość zbiorczą. To dlatego z kilku, kilkudziesięciu albo kilku milionów rekordów możesz dostać jeden wiersz na dział, kraj, miesiąc lub kategorię produktu.

Ja zwykle tłumaczę to tak: baza nie „magicznie” zgaduje odpowiedzi, tylko najpierw wybiera poziom szczegółowości, a dopiero potem liczy wynik. Jeżeli pytasz o sprzedaż per kraj, to poziomem szczegółowości staje się kraj, a nie pojedyncze zamówienie. Taki sposób myślenia bardzo ułatwia pisanie poprawnych zapytań i od razu pokazuje, dlaczego niektóre kolumny trzeba grupować, a inne agregować.

Ważny detal: wartości `NULL` w kolumnie grupującej są zwykle traktowane jako jedna grupa. To oznacza, że brak danych nie rozbija wyniku na wiele części, tylko trafia do jednego wspólnego koszyka. Gdy analizujesz dane produkcyjne, to ma znaczenie częściej, niż się wydaje. Gdy już wiesz, co dzieje się z danymi, warto zobaczyć, jak wygląda poprawna składnia zapytania.

Jak wygląda poprawna składnia i kolejność klauzul

Podstawowy wzór jest prosty, ale dobrze jest zrozumieć nie tylko kolejność zapisu, lecz także kolejność logicznego działania zapytania. Dzięki temu łatwiej przewidzieć, czemu filtr działa albo czemu wynik ma mniej wierszy, niż oczekiwałeś.

SELECT department, COUNT(*) AS liczba_pracownikow, AVG(salary) AS srednia_placa
FROM employees
WHERE active = 1
GROUP BY department
HAVING COUNT(*) >= 5
ORDER BY liczba_pracownikow DESC;

Najprościej zapamiętać to w takiej kolejności: `FROM` pobiera dane, `WHERE` odrzuca niepotrzebne wiersze, `GROUP BY` tworzy grupy, `HAVING` filtruje grupy, `SELECT` zwraca wynik, a `ORDER BY` porządkuje finalną tabelę. To nie jest tylko teoria. Jeśli pomylisz `WHERE` z `HAVING`, zapytanie nadal może wyglądać poprawnie, ale zwróci coś zupełnie innego.

• `WHERE` działa na pojedynczych wierszach przed grupowaniem.
• `HAVING` działa na już policzonych grupach.
• `ORDER BY` nie grupuje danych, tylko sortuje wynik końcowy.
• `GROUP BY` nie służy do ładnego układania rekordów, tylko do zmiany poziomu agregacji.

W praktyce to właśnie ta kolejność decyduje o poprawności raportu. Następny krok to funkcje agregujące, bo bez nich grupowanie zwykle nie daje jeszcze odpowiedzi, której naprawdę szukasz.

Jak łączyć grupowanie z agregatami i filtrem HAVING

Sam `GROUP BY` porządkuje dane, ale dopiero funkcje agregujące robią z tego użyteczny wynik. Najczęściej używam pięciu podstawowych: `COUNT`, `SUM`, `AVG`, `MIN` i `MAX`. Każda odpowiada na inne pytanie, więc dobrze jest wybrać je świadomie, zamiast wrzucać do zapytania „na wszelki wypadek” kilka naraz.

Tu łatwo popełnić mały, ale kosztowny błąd: `COUNT(*)` nie działa tak samo jak `COUNT(kolumna)`. Pierwsza wersja liczy wszystkie wiersze, druga pomija `NULL`. Jeśli więc chcesz policzyć wszystkie zamówienia, `COUNT(*)` jest bezpieczniejszy. Jeśli chcesz policzyć tylko te rekordy, które faktycznie mają wpisaną wartość w danej kolumnie, wybierasz wersję z nazwą kolumny.

`HAVING` wchodzi do gry wtedy, gdy chcesz odfiltrować już policzone grupy. Przykład: interesują Cię tylko te działy, które mają co najmniej pięciu pracowników albo tylko te miasta, w których sprzedaż przekroczyła określony próg. Tego nie załatwi `WHERE`, bo ono działa za wcześnie. Gdy już opanujesz ten podział, dużo łatwiej będzie Ci uniknąć najczęstszych pułapek.

Jakie błędy pojawiają się najczęściej

Najczęstszy problem widzę wtedy, gdy ktoś miesza kolumny grupowane z nieagregowanymi i oczekuje, że SQL „sam wybierze jedną wartość”. W standardowym podejściu to nie działa, bo baza nie ma powodu zgadywać, który rekord ma być reprezentantem grupy. Jeśli więc w `SELECT` pojawia się kolumna, której nie ma ani w `GROUP BY`, ani w funkcji agregującej, zapytanie zwykle kończy się błędem.

• Nieagregowana kolumna w `SELECT` - jeśli nie jest częścią grupy, silnik nie wie, jaką wartość zwrócić.
• Oczekiwanie, że `GROUP BY` posortuje wynik - grupowanie nie gwarantuje kolejności, do tego służy `ORDER BY`.
• Użycie `WHERE` zamiast `HAVING` - filtr działa wtedy w złym miejscu i wynik staje się niepoprawny.
• Grupowanie po zbyt wielu kolumnach - zamiast raportu zbiorczego dostajesz niemal tabelę szczegółową.
• Ignorowanie `NULL` - pustych wartości nie wolno traktować jak drobiazgu, bo potrafią zmienić liczebność grup.

Warto też pamiętać, że niektóre silniki mają własne, mniej rygorystyczne zachowania historyczne, ale nie warto budować na nich logiki aplikacji. Jeśli zależy Ci na przenośności i przewidywalności, trzymaj się zasady: wszystko w wyniku musi być albo grupą, albo agregatem. To prowadzi naturalnie do porównania `GROUP BY` z dwoma innymi mechanizmami, które początkujący często mylą z grupowaniem.

Jak odróżnić grupowanie od distinct i funkcji okienkowych

To jedna z rzeczy, które naprawdę porządkują myślenie o SQL. `GROUP BY`, `DISTINCT` i funkcje okienkowe potrafią dać podobny efekt wizualny, ale robią to w zupełnie inny sposób. Ja zwykle patrzę na nie przez pryzmat pytania: czy chcę zredukować liczbę wierszy, czy tylko dodać do nich kontekst?

SELECT order_id, customer_id, amount,
       SUM(amount) OVER (PARTITION BY customer_id) AS suma_klienta
FROM orders;

Ten przykład pokazuje różnicę bardzo wyraźnie: każdy rekord nadal zostaje w wyniku, ale dostaje dodatkową informację o sumie dla całego klienta. Gdy potrzebujesz raportu „jeden wiersz na klienta”, wybierasz `GROUP BY`. Gdy potrzebujesz pełnej listy zamówień z kontekstem, lepsze będą funkcje okienkowe. A jeśli chcesz tylko unikalne wartości bez liczenia czegokolwiek, wtedy wystarczy `DISTINCT`. Gdy te trzy narzędzia przestają się mylić, można już spokojnie przejść do bardziej zaawansowanych wariantów grupowania.

Kiedy przydają się rollup, cube i grouping sets

W prostych raportach zwykłe grupowanie wystarcza, ale w analizie sprzedaży, finansów czy logów często potrzebujesz także sum częściowych i sumy całkowitej. Wtedy pojawiają się rozszerzenia takie jak `ROLLUP`, `CUBE` i `GROUPING SETS`. Nie są potrzebne w każdym projekcie, ale dobrze wiedzieć, do czego służą, bo w gotowych raportach często je spotkasz.

• `ROLLUP` - dodaje subtotal po kolei, na przykład per kraj, potem per region, a na końcu sumę całkowitą.
• `CUBE` - tworzy wszystkie kombinacje grup, co jest przydatne w analizach wielowymiarowych.
• `GROUPING SETS` - pozwala wskazać dokładnie, które zestawy grup mają się pojawić, bez zgadywania i bez wielu osobnych zapytań.

SELECT region, territory, SUM(sales) AS suma_sprzedazy
FROM sales
GROUP BY ROLLUP(region, territory);

W praktyce `ROLLUP` jest najczęściej używany do raportów hierarchicznych, bo daje subtotal i grand total w jednym zapytaniu. `CUBE` bywa mocniejsze, ale też bardziej kosztowne obliczeniowo, więc nie włączam go odruchowo do dużych tabel bez uzasadnienia. Jeśli raport ma odpowiadać na kilka różnych pytań naraz, `GROUPING SETS` zwykle daje największą kontrolę. Kiedy już znasz te rozszerzenia, łatwiej pisać zapytania, które nie tylko działają, ale też naprawdę nadają się do codziennej analizy.

Co warto zapamiętać, gdy grupowanie staje się częścią większego raportu

Jeżeli chcesz szybko sprawdzić, czy zapytanie jest sensowne, zadaj sobie trzy pytania: co jest jednostką grupy, jaka agregacja ma się pojawić i czy filtr ma działać przed grupowaniem, czy po nim. To prosty test, ale w praktyce bardzo skuteczny. Dla mnie właśnie to jest najważniejsza różnica między pisaniem „działającego” SQL-a a pisaniem SQL-a, który da się utrzymać i rozwinąć. Gdy ten porządek już masz, `SELECT` z `GROUP BY` przestaje być trudnym fragmentem składni, a staje się zwykłym narzędziem do czytelnych analiz.