आम तौर पर उन्हें टाला जाना चाहिए, लेकिन यह विशेषता एक कारण से है और उनका उपयोग करने का समय है। मैं कहूंगा कि मैंने जो कर्सर देखे हैं उनमें से 90+% की जरूरत नहीं है। यदि आप उन्हें सीआरयूडी संचालन के लिए उपयोग कर रहे हैं, तो इसे लगभग हमेशा सेट-आधारित फैशन में फिर से किया जा सकता है। मैंने अक्सर देखा है कि लोग इसके लिए कर्सर का उपयोग करते हैं क्योंकि वे नहीं जानते कि अपडेट में जॉइन का उपयोग कैसे करें या हटाएं या वे एक इंसर्ट में वैल्यू क्लॉज के बजाय एक चुनिंदा स्टेटमेंट का उपयोग कर सकते हैं। एक और अनावश्यक उपयोग जब लोग सोचते हैं कि उन्हें थोड़े अधिक जटिल प्रसंस्करण के लिए उनकी आवश्यकता है जिसे वास्तव में आसानी से एक केस स्टेटमेंट के साथ संभाला जा सकता है।
रनिंग टोटल जैसी किसी चीज़ की गणना करने के लिए कभी-कभी कर्सर तेज़ होते हैं।
एक समय में केवल एक इनपुट मान को संभालने के लिए सेट की गई संग्रहीत प्रो के एकाधिक निष्पादन के लिए कर्सर भी आसान होते हैं। मैं उपयोगकर्ता संग्रहीत प्रोसेस चलाने के लिए इस सुविधा का उपयोग नहीं करता (जब तक मुझे पता नहीं है कि मैं डेटा का एक बहुत छोटा सेट मार रहा हूं) लेकिन कई तालिकाओं के खिलाफ सिस्टम प्रोसेस चलाने की आवश्यकता होने पर डेटाबेस व्यवस्थापक के लिए यह बहुत आसान है।
यदि आप एसक्यूएल में ईमेल बना रहे हैं (ऐसा करने के लिए सबसे अच्छी जगह नहीं है, लेकिन कुछ सिस्टम में वे ऐसा करते हैं) और नहीं चाहते कि ईमेल के पूरे दर्शक सूची में अन्य लोगों को देखें या आप प्रत्येक को वैयक्तिकृत करना चाहते हैं पता करने वाले के बारे में जानकारी के साथ ईमेल, कर्सर जाने का रास्ता है।
कर्सर या लूप का उपयोग रिकॉर्ड के बैचों को संसाधित करने के लिए भी किया जा सकता है यदि संपूर्ण सेट-आधारित इंसर्ट/अपडेट/डिलीट बहुत अधिक समय लेगा और तालिकाओं को लॉक कर देगा। यह कर्सर और सेट-आधारित समाधान के बीच एक प्रकार का संकर है और अक्सर उत्पादन प्रणालियों में बड़े बदलावों के लिए सबसे अच्छा होता है।
