Du sa inte om du planerar att justera "X" och "Y" varje gång du gör sideringen. Om du inte gör det är tillvägagångssättet förmodligen bara giltigt om du har en hög förtroende för att data är ganska statisk.
Tänk på följande exempel:
Min tabell T har 100 rader datumtidsstämpel för "idag", med ID=1 till 100 respektive, och jag vill ha de sista 20 raderna för min första sida. Så jag gör så här:
select *
from T
where date_col = trunc(sysdate)
order by id desc
fetch first 20 rows only
Jag kör min fråga och får ID=100 ner till 80. Så långt har det gått bra - allt finns på användarens sida och de tar 30 sekunder att läsa data. Under den tiden har ytterligare 17 poster lagts till i tabellen (ID=101 till 117).
Nu trycker användaren på "Nästa sida"
Nu kör jag frågan igen för att få nästa uppsättning
select *
from T
where date_col = trunc(sysdate)
order by id desc
offset 20 fetch next 20 rows only
De kommer inte att se rader 80 ner till 60, vilket skulle vara deras förväntningar, eftersom data har ändrats. De skulle
a) hämta rader ID=117 ner till 97, och hoppa över dem på grund av OFFSETb) få sedan rader ID=97 ner till 77 för att visas på skärmen
De kommer att bli förvirrade eftersom de ser ungefär samma uppsättning rader som de gjorde på första sidan.
För paginering mot att ändra data vill man i allmänhet hålla sig borta från offset-klausulen, och använda sin applikation för att notera var man hamnat, dvs
Sida 1
select *
from T
where date_col = trunc(sysdate)
order by id desc
fetch first 20 rows only
Jag hämtar ID=100 ner till 80...jag noterar det av de 80. Min nästa fråga blir då
select *
from T
where date_col = trunc(sysdate)
AND ID<80
order by id desc
fetch first 20 rows only
och min nästa fråga skulle vara
select *
from T
where date_col = trunc(sysdate)
AND ID<60
order by id desc
fetch first 20 rows only
och så vidare.