Anda tidak mengatakan apakah Anda berencana untuk menyesuaikan "X" dan "Y" setiap kali Anda melakukan pagination. Jika tidak, pendekatan mungkin hanya valid jika Anda memiliki keyakinan tinggi bahwa datanya cukup statis.
Perhatikan contoh berikut:
Tabel saya T memiliki cap waktu tanggal 100 baris untuk "hari ini", dengan ID=1 hingga 100 masing-masing, dan saya ingin 20 baris terakhir untuk halaman pertama saya. Jadi saya melakukan ini:
select *
from T
where date_col = trunc(sysdate)
order by id desc
fetch first 20 rows only
Saya menjalankan kueri saya dan mendapatkan ID=100 hingga 80. Sejauh ini bagus - semuanya ada di halaman pengguna, dan mereka membutuhkan waktu 30 detik untuk membaca data. Selama waktu itu, 17 catatan lain telah ditambahkan ke tabel (ID=101 hingga 117).
Sekarang pengguna menekan "Halaman Berikutnya"
Sekarang saya menjalankan kueri lagi untuk mendapatkan set berikutnya
select *
from T
where date_col = trunc(sysdate)
order by id desc
offset 20 fetch next 20 rows only
Mereka tidak akan melihat baris 80 hingga 60, yang akan menjadi harapan mereka, karena data telah berubah. Mereka akan
a) dapatkan baris ID=117 hingga 97, dan lewati karena OFFSETb) lalu dapatkan baris ID=97 hingga 77 untuk ditampilkan di layar
Mereka akan bingung karena mereka melihat rangkaian baris yang hampir sama seperti yang mereka lihat di halaman pertama.
Untuk pagination terhadap perubahan data, Anda biasanya ingin menjauh dari klausa offset, dan menggunakan aplikasi Anda untuk mencatat di mana Anda bangun, yaitu
Halaman 1
select *
from T
where date_col = trunc(sysdate)
order by id desc
fetch first 20 rows only
Saya mengambil ID=100 hingga 80...Saya mencatat dari 80. Permintaan saya selanjutnya adalah
select *
from T
where date_col = trunc(sysdate)
AND ID<80
order by id desc
fetch first 20 rows only
dan pertanyaan saya berikutnya adalah
select *
from T
where date_col = trunc(sysdate)
AND ID<60
order by id desc
fetch first 20 rows only
dan sebagainya.
