Non hai detto se stavi pianificando di regolare "X" e "Y" ogni volta che esegui l'impaginazione. In caso contrario, l'approccio è probabilmente valido solo se si ha un'elevata certezza che i dati siano abbastanza statici.
Considera il seguente esempio:
La mia tabella T ha 100 righe di data e ora per "oggi", rispettivamente con ID =da 1 a 100 e voglio le ultime 20 righe per la mia prima pagina. Quindi faccio questo:
select *
from T
where date_col = trunc(sysdate)
order by id desc
fetch first 20 rows only
Eseguo la mia query e ottengo ID =100 fino a 80. Fin qui tutto bene:è tutto sulla pagina dell'utente e impiegano 30 secondi per leggere i dati. Durante questo periodo sono stati aggiunti alla tabella altri 17 record (ID=101 a 117).
Ora l'utente preme "Pagina successiva"
Ora eseguo di nuovo la query per ottenere il set successivo
select *
from T
where date_col = trunc(sysdate)
order by id desc
offset 20 fetch next 20 rows only
Non vedranno le righe da 80 a 60, che sarebbe la loro aspettativa, perché i dati sono cambiati. Lo farebbero
a) ottieni le righe ID=117 fino a 97 e saltale a causa dell'OFFSETb) quindi ottieni le righe ID=97 fino a 77 da visualizzare sullo schermo
Saranno confusi perché vedono più o meno lo stesso insieme di righe della prima pagina.
Per l'impaginazione contro la modifica dei dati, in genere si desidera evitare la clausola di offset e utilizzare l'applicazione per prendere nota di dove si è arrivati, ad esempio
Pagina 1
select *
from T
where date_col = trunc(sysdate)
order by id desc
fetch first 20 rows only
Recupero ID=100 fino a 80... prendo nota degli 80. La mia prossima domanda sarà quindi
select *
from T
where date_col = trunc(sysdate)
AND ID<80
order by id desc
fetch first 20 rows only
e la mia prossima domanda sarebbe
select *
from T
where date_col = trunc(sysdate)
AND ID<60
order by id desc
fetch first 20 rows only
e così via.
