Du sagde ikke, om du planlagde at justere "X" og "Y" hver gang du foretager pagineringen. Hvis du ikke gør det, er tilgang sandsynligvis kun gyldig, hvis du har en høj tillid til, at dataene er ret statiske.
Overvej følgende eksempel:
Min tabel T har 100 rækker dato-tidsstempel for "i dag", med henholdsvis ID=1 til 100, og jeg vil have de sidste 20 rækker til min første side. Så jeg gør dette:
select *
from T
where date_col = trunc(sysdate)
order by id desc
fetch first 20 rows only
Jeg kører min forespørgsel og får ID=100 ned til 80. Så langt så godt - det hele er på brugerens side, og de tager 30 sekunder minutter at læse dataene. I løbet af den tid er yderligere 17 poster blevet tilføjet til tabellen (ID=101 til 117).
Nu trykker brugeren på "Næste side"
Nu kører jeg forespørgslen igen for at få det næste sæt
select *
from T
where date_col = trunc(sysdate)
order by id desc
offset 20 fetch next 20 rows only
De vil ikke se rækker 80 ned til 60, hvilket ville være deres forventning, fordi dataene er ændret. Det ville de
a) få rækker ID=117 ned til 97, og springe dem over på grund af OFFSETb) og derefter få rækker ID=97 ned til 77 for at blive vist på skærmen
De vil blive forvirrede, fordi de ser stort set det samme sæt rækker, som de gjorde på den første side.
For paginering mod ændring af data, vil du generelt holde dig fra offset-klausulen, og bruge din applikation til at notere dig, hvor du er nået op, dvs.
Side 1
select *
from T
where date_col = trunc(sysdate)
order by id desc
fetch first 20 rows only
Jeg henter ID=100 ned til 80...Jeg noterer det af de 80. Min næste forespørgsel vil så være
select *
from T
where date_col = trunc(sysdate)
AND ID<80
order by id desc
fetch first 20 rows only
og min næste forespørgsel ville være
select *
from T
where date_col = trunc(sysdate)
AND ID<60
order by id desc
fetch first 20 rows only
og så videre.