Okienko danych - dziwne działanie ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING

0

Cześć,
zacząłem się ostatnio uczyć T-SQL'a więc wielkim znawcą póki co nie jestem, więc mój problem być może jest trywialny za co z góry przepraszam.

Stworzyłem prostą tabelę, która zawiera wyniki meczów. W ramach ćwiczenia napisałem poniższe zapytanie

SELECT *,
SUM(GOLE_D) OVER(PARTITION BY GOSPODARZ
				 ORDER BY GOSPODARZ
				 ROWS  UNBOUNDED PRECEDING
				 ) AS X1,
SUM(GOLE_D) OVER(PARTITION BY GOSPODARZ
				 ORDER BY GOSPODARZ
				 ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING 
				 ) AS X2,
SUM(GOLE_D) OVER(PARTITION BY GOSPODARZ
				 ORDER BY GOSPODARZ
				 ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING
				 ) AS X3

FROM MECZE;

którego celem jest liczenie sumy goli (GOLE_D - dokładnie gole strzelone przez gospodarzy):

a) narastająco od początku partycji do danego wiersza - działa poprawnie (X1),
b) od wiersza poprzedzającego do następującego - działa poprawnie (X3),

oraz
c) spełzająco od danego wiersza do końca partycji (X2).

I tutaj się pojawia problem. Otóż wynik w kolumnach X1 oraz X2 jest dokładnie taki sam.
screenshot-20210630210649.png

Dlaczego zastosowanie ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING daje ten sam wynik co ROWS UNBOUNDED PRECEDING?
Z góry dzięki za pomoc :)

0

Dzielisz zbiór po "GOSPODARZ", a później porządkujesz po polu "GOSPODARZ", czyli jaki masz porządek GOLE_D w ramach takiej partycji?

0

Domyślałem, że problem może tkwić w tym, że podział oraz porządek są po kolumnie "GOSPODARZ" bo gdy sortuję po kolumnie "GOSC", to wynik jest poprawny.

Ale zaciekawiło mnie to czemu w kolumnach X1 oraz X3 otrzymuję wyniki jakich oczekiwałem, a X2 nie, skoro w X1, X2 oraz X3 sortowanie jest po gospodarzu, czyli wszędzie kolejność wierszy jest taka sama czyli taka jak w tabeli MECZE. Bo sortowanie po gospodarzu nic (chyba) nie zmienia skoro podział na partycje jest również po tej kolumnie.

2

Czysto strzelam, bo aż tak na T-SQL się nie znam, ale PARTITION BY column ORDER BY column oznacza, że wewnątrz partycji kolejność może być absolutnie dowolna (bo sortujesz po wartości współdzielonej przez wszystkie wiersze, i tylko po niej). Więc planer może sobie założyć, że kolejność nie jest istotna. W związku z tym może sobie "zoptymalizować" zapytanie poprzez założenie, że X1 będzie posortowane w jednym kierunku, a X2 dokładnie w odwrotnym (przypominam, w Twoim zapytaniu kolejność nie ma znaczenia), dzięki czemu może uniknąć liczenia logicznie tej samej wartości podwójnie.

2

Robisz partycje po GOSPODARZ czyli będziesz miał dane tylko np dla GOSPODARZa z numerem 1 i teraz sortujesz po tej jedynce. Moim zdaniem to, co osiągnąłeś jest zupełnym przypadkiem i jak na przykład rozdzielisz to na dwa zapytania juz wyniki nie będą takie same.
Zrób np tak

SELECT *,
SUM(GOLE_D) OVER(PARTITION BY GOSPODARZ
                 ORDER BY Data_meczu 
                 ROWS  UNBOUNDED PRECEDING
                 ) AS X1,
SUM(GOLE_D) OVER(PARTITION BY GOSPODARZ
                 ORDER BY Data_meczu 
                 ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING 
                 ) AS X2,
SUM(GOLE_D) OVER(PARTITION BY GOSPODARZ
                 ORDER BY Data_meczu 
                 ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING
                 ) AS X3

FROM MECZE;

I zobacz jak to wygląda.

0

@UglyMan: Wynik Twojego zapytania wygląda u mnie tak:
screenshot-20210701235542.png

Więc wychodzi na to, że jeśli się sql-serwerowi nie powie konkretnie jaki ma być porządek wierszy użyty do obliczeń, to zrobi to tak aby jemu było najwygodniej. I porządek wierszy, który jest widoczny nie musi przecież być tym użytym do obliczeń.

Chyba już rozumiem. Dziękuję za odpowiedzi.

1 użytkowników online, w tym zalogowanych: 0, gości: 1