आपने यह नहीं बताया कि क्या आप हर बार पेजिनेशन करने पर "X" और "Y" को एडजस्ट करने की योजना बना रहे हैं। यदि आप नहीं करते हैं तो दृष्टिकोण शायद केवल तभी मान्य है जब आपको उच्च विश्वास हो कि डेटा काफी स्थिर है।
निम्नलिखित उदाहरण पर विचार करें:
मेरी तालिका टी में क्रमशः आईडी =1 से 100 के साथ "आज" के लिए 100 पंक्तियों की तारीख टाइमस्टैम्प है, और मुझे अपने पहले पृष्ठ के लिए अंतिम 20 पंक्तियां चाहिए। तो मैं यह करता हूं:
select *
from T
where date_col = trunc(sysdate)
order by id desc
fetch first 20 rows only
मैं अपनी क्वेरी चलाता हूं और आईडी =100 से 80 तक नीचे आता हूं। अब तक बहुत अच्छा है - यह सब उपयोगकर्ता के पेज पर है, और डेटा को पढ़ने में उन्हें 30 सेकंड का समय लगता है। उस समय के दौरान, तालिका में एक और 17 रिकॉर्ड जोड़े गए हैं (ID=101 से 117)।
अब उपयोगकर्ता "अगला पृष्ठ" दबाता है
अब मैं अगला सेट प्राप्त करने के लिए फिर से क्वेरी चलाता हूं
select *
from T
where date_col = trunc(sysdate)
order by id desc
offset 20 fetch next 20 rows only
वे पंक्तियों को 80 से 60 तक नहीं देखेंगे, जो उनकी अपेक्षा होगी, क्योंकि डेटा बदल गया है। वे करेंगे
a) पंक्तियाँ ID=117 से 97 तक प्राप्त करें, और OFFSETb के कारण उन्हें छोड़ दें) फिर स्क्रीन पर प्रदर्शित होने के लिए पंक्तियाँ ID=97 से 77 तक प्राप्त करें
वे भ्रमित होंगे क्योंकि वे पंक्तियों के समान सेट को देख रहे हैं जैसा कि उन्होंने पहले पृष्ठ पर किया था।
बदलते डेटा के खिलाफ पेजिनेशन के लिए, आप आम तौर पर ऑफसेट क्लॉज से दूर रहना चाहते हैं, और अपने एप्लिकेशन का उपयोग यह नोट करने के लिए करते हैं कि आप कहां पहुंचे, यानी
पेज 1
select *
from T
where date_col = trunc(sysdate)
order by id desc
fetch first 20 rows only
मैं आईडी =100 से 80 तक नीचे लाता हूं...मैं ध्यान देता हूं 80 में से। मेरी अगली क्वेरी तब होगी
select *
from T
where date_col = trunc(sysdate)
AND ID<80
order by id desc
fetch first 20 rows only
और मेरी अगली क्वेरी होगी
select *
from T
where date_col = trunc(sysdate)
AND ID<60
order by id desc
fetch first 20 rows only
और आगे।
