छोटे इंट्रानेट अनुप्रयोगों में पेजिंग के लिए कर्सर एक उचित विकल्प हैं जो बड़े डेटा सेट के साथ काम करते हैं, लेकिन आपको टाइमआउट के बाद उन्हें त्यागने के लिए तैयार रहने की आवश्यकता है। उपयोगकर्ता भटकना, दोपहर के भोजन पर जाना, दो सप्ताह के लिए छुट्टी पर जाना आदि पसंद करते हैं और अपने आवेदनों को चालू रखना पसंद करते हैं। यदि यह एक वेब-आधारित ऐप है, तो यह भी सवाल है कि "रनिंग" क्या है और यह कैसे बताया जाए कि उपयोगकर्ता अभी भी आसपास है या नहीं।
वे उच्च ग्राहक संख्या वाले बड़े पैमाने के अनुप्रयोगों और वेब-आधारित ऐप्स या वेब एपीआई की तरह लगभग-यादृच्छिक रूप से आने और जाने वाले क्लाइंट के लिए उपयुक्त नहीं हैं। मैं आपके आवेदन में कर्सर का उपयोग करने की अनुशंसा नहीं करता जब तक कि आपके पास काफी छोटी ग्राहक संख्या और बहुत अधिक अनुरोध दर न हो ... जिस स्थिति में पंक्तियों के छोटे बैच भेजना बहुत अक्षम होगा और आपको इसके बजाय रेंज-अनुरोध आदि की अनुमति देने के बारे में सोचना चाहिए।
कर्सर की कई लागतें होती हैं। यदि कर्सर WITH HOLD नहीं है आपको एक लेनदेन खुला रखना चाहिए। खुला लेनदेन ऑटोवैक्यूम को अपना काम ठीक से करने से रोक सकता है, जिससे टेबल ब्लोट और अन्य समस्याएं हो सकती हैं। यदि कर्सर को WITH HOLD घोषित किया जाता है और लेन-देन खुला नहीं है, आपको संभावित रूप से बड़े परिणाम सेट को भौतिक बनाने और संग्रहीत करने की लागत का भुगतान करना होगा - कम से कम, मुझे लगता है कि कर्सर कैसे काम करते हैं। विकल्प उतना ही बुरा है, लेन-देन को तब तक खुला रखना जब तक कि कर्सर नष्ट न हो जाए और पंक्तियों को साफ होने से रोक दिया जाए।
इसके अतिरिक्त, यदि आप कर्सर का उपयोग कर रहे हैं तो आप कनेक्शन को वापस कनेक्शन पूल में नहीं सौंप सकते। आपको प्रति ग्राहक एक कनेक्शन की आवश्यकता होगी। इसका मतलब है कि अधिक बैकएंड संसाधनों का उपयोग केवल सत्र स्थिति को बनाए रखने के लिए किया जाता है, और उन ग्राहकों की संख्या पर एक बहुत ही वास्तविक ऊपरी सीमा निर्धारित करता है जिन्हें आप कर्सर-आधारित दृष्टिकोण से संभाल सकते हैं।
सीमा और ऑफसेट के साथ स्टेटलेस कनेक्शन-पूलिंग दृष्टिकोण की तुलना में एक स्टेटफुल, कर्सर-आधारित सेटअप को प्रबंधित करने की जटिलता और ओवरहेड भी है। आपको अपने एप्लिकेशन की समयबाह्य समाप्ति के बाद कर्सर की समय सीमा समाप्त करने की आवश्यकता है या आप सर्वर पर संभावित रूप से असीमित संसाधन उपयोग का सामना करते हैं, और आपको यह ट्रैक रखने की आवश्यकता है कि किन कनेक्शनों में कौन से कर्सर हैं जिसके लिए परिणाम किस उपयोगकर्ता के लिए सेट करता है....
सामान्य तौर पर, इस तथ्य के बावजूद कि यह काफी अक्षम हो सकता है, LIMIT और OFFSET बेहतर समाधान हो सकता है। OFFSET . का उपयोग करने के बजाय प्राथमिक कुंजी खोजना अक्सर बेहतर हो सकता है , हालांकि।
वैसे, आप PL/pgSQL में कर्सर के लिए दस्तावेज़ देख रहे थे। आप इस कार्य के लिए सामान्य SQL-स्तरीय कर्सर चाहते हैं।
<ब्लॉकक्वॉट>क्या कर्सर के लिए आवश्यक है कि एक डेटाबेस कनेक्शन खुला छोड़ दिया जाए?
हाँ।
<ब्लॉकक्वॉट>क्या कर्सर लेन-देन के अंदर चलते हैं, संसाधनों को "बंद" होने तक लॉक करते हैं?
हाँ, जब तक कि वे WITH HOLD न हों , जिस स्थिति में वे अन्य डेटाबेस संसाधनों का उपभोग करते हैं।
क्या कोई अन्य "गॉथचास" है जिसके बारे में मुझे जानकारी नहीं है?
हां, जैसा कि ऊपर बताया गया है।
