Funkcje okienne pozwalają na przeprowadzanie obliczeń w "oknie" wierszy, nie grupując ich w osobne wiersze, co jest wygodne dla raportów i analizy.
Przykład:
SELECT name, salary, ROW_NUMBER() OVER (ORDER BY salary DESC) AS num, RANK() OVER (ORDER BY salary DESC) AS rank, DENSE_RANK() OVER (ORDER BY salary DESC) AS dense_rank FROM employees;
Tabela:
| name | salary |
|---|---|
| Wania | 10000 |
| Pietia | 10000 |
| Masza | 9000 |
Wynik:
| name | salary | num | rank | dense_rank |
|---|---|---|---|---|
| Wania | 10000 | 1 | 1 | 1 |
| Pietia | 10000 | 2 | 1 | 1 |
| Masza | 9000 | 3 | 3 | 2 |
Pułapki:
Jeśli nie zostanie podany PARTITION BY w funkcji okiennej, jak będzie przebiegać numeracja wierszy w ROW_NUMBER()?
Odpowiedź: Cały zestaw danych będzie uznawany za jedną partię. To znaczy, numeracja będzie ciągła dla wszystkich wierszy, bez uwzględnienia jakichkolwiek grup.
Przykład:
SELECT *, ROW_NUMBER() OVER (ORDER BY salary DESC) FROM employees; -- Wszyscy pracownicy otrzymają unikalny numer, zaczynając od 1 bez podziału na działy
Historia nr 1
W raporcie BI zapomniano wskazać PARTITION BY według działu. Wszyscy pracownicy firmy otrzymali ciągłą numerację, mimo że zadanie polegało na zidentyfikowaniu najlepszych w każdym dziale. W rezultacie uzyskano niepoprawny TOP-N pracowników według działów.
Historia nr 2
Programista wybrał RANK() zamiast ROW_NUMBER(), aby określić "najlepszego" w grupie — ale przy identycznych wynikach przypisano ten sam numer, przez co powstały niejawne duplikaty liderów w analizie.
Historia nr 3
Przy użyciu DENSE_RANK() nie uwzględniono, że zabrania on luk w rankingach, co zaburzyło raport dotyczący liczby "unikalnych" istotnych pozycji podczas analizy sprzedaży. Kontrola logiki biznesowej ujawniła błąd w rozkładzie miejsc.