Vous n'avez pas dit si vous prévoyiez d'ajuster "X" et "Y" à chaque fois que vous faites la pagination. Si vous ne le faites pas, l'approche n'est probablement valable que si vous avez une grande confiance dans le fait que les données sont assez statiques.
Prenons l'exemple suivant :
Ma table T a 100 lignes d'horodatage de date pour "aujourd'hui", avec ID =1 à 100 respectivement, et je veux les 20 dernières lignes pour ma première page. Alors je fais ceci :
select *
from T
where date_col = trunc(sysdate)
order by id desc
fetch first 20 rows only
J'exécute ma requête et j'obtiens ID =100 jusqu'à 80. Jusqu'ici tout va bien - tout est sur la page de l'utilisateur, et ils prennent 30 secondes pour lire les données. Pendant ce temps, 17 autres enregistrements ont été ajoutés à la table (ID=101 à 117).
Maintenant, l'utilisateur appuie sur "Page suivante"
Maintenant, j'exécute à nouveau la requête pour obtenir l'ensemble suivant
select *
from T
where date_col = trunc(sysdate)
order by id desc
offset 20 fetch next 20 rows only
Ils ne verront pas les lignes 80 à 60, ce qui serait leur attente, car les données ont changé. Ils
a) obtenir les lignes ID=117 jusqu'à 97, et les ignorer en raison de l'OFFSETb) puis obtenir les lignes ID=97 jusqu'à 77 à afficher à l'écran
Ils seront confus car ils verront à peu près le même ensemble de lignes que sur la première page.
Pour la pagination contre la modification des données, vous voulez généralement rester à l'écart de la clause de décalage et utiliser votre application pour noter où vous en êtes, c'est-à-dire
Page 1
select *
from T
where date_col = trunc(sysdate)
order by id desc
fetch first 20 rows only
Je récupère ID=100 jusqu'à 80... Je prenez note des 80. Ma prochaine requête sera alors
select *
from T
where date_col = trunc(sysdate)
AND ID<80
order by id desc
fetch first 20 rows only
et ma prochaine requête serait
select *
from T
where date_col = trunc(sysdate)
AND ID<60
order by id desc
fetch first 20 rows only
et ainsi de suite.
