SQL OVER () -sætningen – hvornår og hvorfor er det nyttigt?

Så med enkle ord: Over-sætning kan bruges til at vælge ikke-aggregerede værdier sammen med aggregerede.

Partition BY, ORDER BY inde og ROWS eller RANGE er en del af OVER () efter klausul.

partition by bruges til at partitionere data og derefter udføre disse vinduer, aggregerede funktioner, og hvis vi ikke have partition af det daværende hele resultatsæt betragtes som en enkelt partition.

Lad os se grundlæggende syntaks for OVER-klausul

PARTITION BY: Det bruges til at opdele data og udføre operationer på grupper med de samme data.

ORDER BY: Det bruges til at definere den logiske rækkefølge af data i Partitioner. Når vi ikke angiver partition, betragtes hele resultatsæt som en enkelt partition

: Dette kan bruges til at specificere, hvilke rækker der skal betragtes som en partition, når operationen udføres.

Lad os tage et eksempel:

Her er mit datasæt:

Så lad mig udføre forskellige scenarier og se, hvordan data påvirkes, og jeg kommer fra vanskelig syntaks til enkel en

Bare observer sum_sal-delen. Her bruger jeg rækkefølge efter løn og bruger “RANGE MELLEM UBEGRENSET FORUDGÅENDE OG LØBENDE RÆDE”. I dette tilfælde bruger vi ikke partition, så hele data vil blive behandlet som en partition, og vi bestiller løn. Og det vigtige her er UBEGRÆNSET FORUDGÅENDE OG LØBENDE RÆDE. Det betyder, når vi beregner summen, fra startrække til den aktuelle række for hver række. Men hvis vi ser rækker med løn 5000 og navn = “Pavan”, ideelt set skal det være 17000 og for løn = 5000 og navn = Mark, skal det være 22000. Men da vi bruger RANGE og i dette tilfælde, hvis det finder nogen s imilar elementer, så betragter de dem som den samme logiske gruppe og udfører en operation på dem og tildeler værdi til hvert element i den gruppe. Det er grunden til, at vi har den samme værdi for løn = 5000. Motoren gik op til løn = 5000 og Navn = Ron og beregnede summen og tildelte den derefter til alle løn = 5000.

Så med RÆKER MELLEM UBEGRÆNSET FORUDGÅENDE OG LØBENDE RÆK Forskellen er for samme værdi poster i stedet for gruppere dem sammen, det beregner SUM fra start række til nuværende række, og det behandler ikke varer med samme værdi forskelligt som RANGE

Disse resultater er de samme som

Det skyldes, at Over (ordre efter løn) bare er en genvej til Over (rækkefølge efter løn RANGE MELLEM UBEGRÆNSET FORUDGÅENDE OG LØBENDE RÆDE) Så uanset hvor vi blot angiver Ordne efter uden RÆKKER eller RÆKKE det tager RANGE MELLEM Ubegrænset forudgående og aktuel række som standard.

Bemærk: Dette gælder kun for funktioner, der faktisk accepterer RANGE / ROW. For eksempel ROW_NUMBER og få andre accepterer ikke RANGE / ROW, og i så fald , dette kommer ikke ind i billedet.

Indtil nu så vi, at Over-klausul med en ordre ved tager Range / ROWS og syntaksen ser noget ud hænger som dette RANGE MELLEM UBEGRÆNSET FORUDGÅENDE OG LØBENDE RÆDE, og det beregnes faktisk op til den aktuelle række fra første række. Men hvad hvis det vil beregne værdier for hele datadeling og have det for hver kolonne (det er fra 1. række til sidste række). Her er forespørgslen for det

I stedet for CURRENT ROW specificerer jeg Ubegrænset FØLGENDE, som instruerer motoren til at beregne til den sidste partitionspost for hver række.

Kommer nu til din peg på hvad der er OVER () med tomme seler?

Det er bare en genvej til Over (rækkefølge efter løn RÆKER MELLEM UBEGRÆNSET FORUDGÅENDE OG UBEGRÆNSET FØLGENDE)

Her specificerer vi indirekte at behandle alle mine resultatsæt som en enkelt partition og derefter udføre beregninger fra den første post til den sidste record for hver partition.

Jeg lavede en video om dette, og hvis du er interesseret, kan du besøge den. https://www.youtube.com/watch?v=CvVenuVUqto&t=1177s

Tak, Pavan Kumar AryasomayajuluHTTP: //xyzcoder.github.io

Write a Comment

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *