Tehát egyszerű szavakkal: Az Over záradék használható a nem összesített értékek és az összesített értékek kiválasztására is.

A partíció BY, a ORDER BY belül, és a ROWS vagy a RANGE az OVER () kifejezés része.

A partition by az adatok particionálására szolgál, majd végrehajtja ezeket az ablakokat, összesített függvényeket, és ha nem ” Ha a partíciót akkor az egész eredménykészlet egyetlen partíciónak tekinti.

Lássuk az OVER záradék alapvető szintaxisát

PARTITION BY: Az adatok particionálására és ugyanazokkal az adatokkal rendelkező csoportok műveleteinek végrehajtására szolgál.

ORDER BY: A partíciókban az adatok logikai sorrendjének meghatározására szolgál. Ha nem adjuk meg a partíciót, akkor a teljes eredménykészlet egyetlen partíciónak tekinthető.

: Ezzel meghatározható, hogy a művelet végrehajtásakor milyen sorokat kell figyelembe venni a partícióban.

Vegyünk egy példát:

Itt van az adatkészletem:

Tehát hadd futtassak különféle forgatókönyveket, és nézzem meg, hogyan hatnak az adatok, és a nehéz szintaxisból az egyszerűbe fogok jönni egy

Csak vegye figyelembe a sum_sal részt. Itt a Fizetés szerinti sorrendet használom, és a “KÖRNYEZETT ELŐZETT ELŐZETES ÉS AKTUÁLIS SOR KÖZÖTT”. Ebben az esetben nem partíciót használunk, így a teljes adatot egyként kezeljük. particionálunk, és fizetés alapján rendelünk. És itt a legfontosabb a FELTÉTELT ELŐZETES ÉS JELENLEGI SOR. Ez azt jelenti, hogy amikor kiszámítjuk az összeget, a kezdő sortól az egyes sorok aktuális soráig. De ha 5000-ös fizetéssel és névvel rendelkező sorokat látunk = “Pavan”, ideális esetben 17000, fizetés = 5000 és név = Mark esetén pedig 22000. De mivel a RANGE-t használjuk, és ebben az esetben, ha talál s hasonló elemeket, akkor ugyanannak a logikai csoportnak tekinti, és végrehajt egy műveletet rajtuk, és értéket rendel a csoport minden eleméhez. Ez az oka annak, hogy a fizetés értéke azonos = 5000. A motor felmért a fizetés = 5000 és a név = Ron értékre, és kiszámította az összeget, majd hozzárendelte az összes fizetés = 5000 értékhez. csoportosítva őket, kiszámítja az SUM értéket a kezdő sorból az aktuális sorba, és nem kezeli másként az azonos értékű elemeket, mint a RANGE

Ezek az eredmények megegyeznek a

Ennek az az oka, hogy az Over (sorrend fizetésenként) csak egy rövidítés az Over-től (sorrend fizetésenként KÖRNYEZETT ELŐZMÉNYEK ÉS JELENLEGI SOR KÖZÖTT) Tehát bárhol egyszerűen megadjuk a Sorrendet ROWS vagy RANGE nélkül, amit vesz VÁLASZTOTT ELŐZETT ÉS ELJÁRÓ SOR KÖZÖTT Alapértelmezés szerint.

Megjegyzés: Ez csak azokra a funkciókra vonatkozik, amelyek ténylegesen elfogadják a RANGE / ROW parancsot. Például a ROW_NUMBER és néhány más nem fogadja el a RANGE / ROW-ot, és ebben az esetben , ez nem jön be a képbe.

Mostanáig láttuk, hogy az Over záradék egy rendeléssel a Range / ROWS értéket veszi fel, és a szintaxis néha kinéz ilyen a HATÁR NÉLKÜL ELŐZETT ELŐZŐ ÉS A JELENLEGI SOR KÖZÖTT. És valójában az első sor aktuális soráig számít. De mi van, ha ki akarja számítani az adatok teljes partíciójának értékeit, és minden oszlophoz megkapja azokat (vagyis az 1. sortól az utolsó sorig). Itt van erre a lekérdezés.

A CURRENT ROW helyett az UNBOUNDED FOLLOWING értéket adom meg, amely utasítja a motort, hogy számoljon az egyes sorok partíciójának utolsó rekordjáig.

Most jön a rámutat arra, hogy mi az OVER () üres zárójelekkel?

Ez csak egy rövidítés az Over számára (fizetés szerinti sorrend KÖTELEZŐ ELŐZETT ÉS KÖVETKEZŐ KÖVETKEZŐKÖZÖTT)

Itt közvetve meghatározzuk hogy az összes eredménykészletemet egyetlen partícióként kezeljem, majd elvégezzem a számításokat az első rekordtól az egyes partíciók utolsó rekordjáig.

Létrehoztam egy videót erről, és ha érdekel, felkeresheted. https://www.youtube.com/watch?v=CvVenuVUqto&t=1177s

Köszönöm, Pavan Kumar AryasomayajuluHTTP: //xyzcoder.github.io