No dijiste si planeabas ajustar "X" e "Y" cada vez que haces la paginación. Si no lo hace, entonces el enfoque probablemente solo sea válido si tiene una gran confianza en que los datos son bastante estáticos.
Considere el siguiente ejemplo:
Mi tabla T tiene una marca de fecha y hora de 100 filas para "hoy", con ID =1 a 100 respectivamente, y quiero las últimas 20 filas para mi primera página. Así que hago esto:
select *
from T
where date_col = trunc(sysdate)
order by id desc
fetch first 20 rows only
Ejecuto mi consulta y obtengo ID =100 hasta 80. Hasta ahora todo bien:todo está en la página del usuario, y tardan 30 segundos en leer los datos. Durante ese tiempo, se agregaron otros 17 registros a la tabla (ID=101 a 117).
Ahora el usuario presiona "Página siguiente"
Ahora vuelvo a ejecutar la consulta para obtener el siguiente conjunto
select *
from T
where date_col = trunc(sysdate)
order by id desc
offset 20 fetch next 20 rows only
No verán las filas 80 a 60, que sería su expectativa, porque los datos han cambiado. Ellos
a) baje las filas ID=117 a 97 y sáltelas debido al DESPLAZAMIENTOb) luego baje las filas ID=97 a 77 para que se muestren en la pantalla
Estarán confundidos porque ven prácticamente el mismo conjunto de filas que vieron en la primera página.
Para la paginación contra el cambio de datos, generalmente desea mantenerse alejado de la cláusula de compensación y usar su aplicación para tomar nota de dónde llegó, es decir,
Página 1
select *
from T
where date_col = trunc(sysdate)
order by id desc
fetch first 20 rows only
Busco ID=100 hasta 80... tomo nota de los 80. Mi próxima consulta será entonces
select *
from T
where date_col = trunc(sysdate)
AND ID<80
order by id desc
fetch first 20 rows only
y mi próxima consulta sería
select *
from T
where date_col = trunc(sysdate)
AND ID<60
order by id desc
fetch first 20 rows only
y así sucesivamente.
