Je hebt niet gezegd of je van plan was om "X" en "Y" aan te passen elke keer dat je de paginering uitvoert. Als je dat niet doet, is de aanpak waarschijnlijk alleen geldig als je er een hoog vertrouwen in hebt dat de gegevens redelijk statisch zijn.
Beschouw het volgende voorbeeld:
Mijn tabel T heeft een datum-tijdstempel van 100 rijen voor "vandaag", met respectievelijk ID =1 tot 100, en ik wil de laatste 20 rijen voor mijn eerste pagina. Dus ik doe dit:
select *
from T
where date_col = trunc(sysdate)
order by id desc
fetch first 20 rows only
Ik voer mijn query uit en krijg ID=100 tot 80. Tot nu toe gaat het goed - het staat allemaal op de gebruikerspagina en het duurt 30 seconden om de gegevens te lezen. In die tijd zijn er nog eens 17 records aan de tabel toegevoegd (ID=101 tot 117).
Nu drukt de gebruiker op "Volgende pagina"
Nu voer ik de query opnieuw uit om de volgende set te krijgen
select *
from T
where date_col = trunc(sysdate)
order by id desc
offset 20 fetch next 20 rows only
Ze zullen de rijen 80 tot 60 niet zien, wat hun verwachting zou zijn, omdat de gegevens zijn veranderd. Ze zouden
a) haal rijen ID=117 naar beneden tot 97, en sla ze over vanwege de OFFSETb) haal dan rijen ID=97 naar beneden tot 77 om op het scherm weer te geven
Ze zullen in de war zijn omdat ze vrijwel dezelfde reeks rijen zien als op de eerste pagina.
Voor paginering tegen veranderende gegevens, wilt u over het algemeen wegblijven van de offset-clausule en uw applicatie gebruiken om kennis te nemen van waar u bent uitgekomen, dat wil zeggen
Pagina 1
select *
from T
where date_col = trunc(sysdate)
order by id desc
fetch first 20 rows only
Ik haal ID=100 op tot 80...Ik let op van de 80. Mijn volgende vraag is dan
select *
from T
where date_col = trunc(sysdate)
AND ID<80
order by id desc
fetch first 20 rows only
en mijn volgende vraag zou zijn
select *
from T
where date_col = trunc(sysdate)
AND ID<60
order by id desc
fetch first 20 rows only
enzovoort.