लोग SQL कर्सर से इतनी नफरत क्यों करते हैं? [बन्द है]

Question

मैं समझ सकता हूं कि ओवरहेड और असुविधा के कारण कर्सर का उपयोग करने से बचना चाहते हैं, लेकिन ऐसा लगता है कि कुछ गंभीर कर्सर-फोबिया-उन्माद चल रहा है जहां लोग एक का उपयोग करने से बचने के लिए बड़ी लंबाई में जा रहे हैं।

उदाहरण के लिए, एक प्रश्न ने पूछा कि एक कर्सर के साथ कुछ स्पष्ट रूप से तुच्छ कैसे किया जाए और एक सामान्य तालिका अभिव्यक्ति (CTE) पुनरावर्ती कस्टम फ़ंक्शन के साथ पुनरावर्ती क्वेरी का उपयोग करके प्रस्तावित उत्तर को प्रस्तावित किया जाए, भले ही यह पंक्तियों की संख्या को 32 तक संसाधित कर सके। (SQL सर्वर में पुनरावर्ती फ़ंक्शन कॉल सीमा के कारण)। यह मुझे सिस्टम दीर्घायु के लिए एक भयानक समाधान के रूप में प्रभावित करता है, न कि केवल एक साधारण कर्सर का उपयोग करने से बचने के लिए एक जबरदस्त प्रयास का उल्लेख करने के लिए।

इस घृणा के स्तर का कारण क्या है? क्या कुछ? विख्यात प्राधिकरण ’ने शाप देने वालों के खिलाफ फतवा जारी किया है? क्या कुछ अकथनीय बुराई श्राप देने वालों के दिल में आग लगा देती है, जो बच्चों या अन्य लोगों की नैतिकता को दूषित करता है?

विकी सवाल, रेप के जवाब से ज्यादा दिलचस्पी।

संबंधित जानकारी:

SQL सर्वर फास्ट फॉरवर्ड कर्सर

संपादित करें: मुझे अधिक सटीक होने दें: मैं समझता हूं कि सामान्य रिलेशनल ऑपरेशंस के बजाय कर्सर का उपयोग नहीं किया जाना चाहिए ; यह एक दिमाग नहीं है। मुझे समझ में नहीं आता है कि लोग वाह-वाही से बचने के लिए अपने रास्ते से बाहर जा रहे हैं जैसे कि उनके पास कूट या कुछ है, तब भी जब कोई कर्सर सरल और / या अधिक कुशल समाधान होता है। यह तर्कहीन घृणा है जो मुझे चकित करती है, न कि स्पष्ट तकनीकी क्षमता को।

Comments

मुझे लगता है कि आपका संपादन यह सब कहता है ... लगभग सभी स्थितियों में (जो कि मैं भर आया हूं) एक कर्सर को बेहतर प्रदर्शन करने वाले सेट आधारित स्थिति से बदलने का एक तरीका है। आप कहते हैं न-ब्रेनर, लेकिन आप अंतर को समझते हैं।

— स्टिंगजैक

मैं इस सवाल पर टैग प्यार करता हूँ!

— sep332

पुनरावर्ती CTE सीमा के बारे में हिस्सा 32बकवास है। संभवतः आप पुनरावर्ती ट्रिगर और अधिकतम @@NESTLEVELके बारे में सोच रहे हैं 32। इसे OPTION (MAXRECURSION N)डिफ़ॉल्ट 100और 0अर्थ असीमित के साथ क्वेरी में सेट किया जा सकता है ।

— मार्टिन स्मिथ

@MartinSmith: डिफ़ॉल्ट सीमा अब 100 है, और अधिकतम 32K sql-server-helper.com/error-messages/msg-310.aspx

— स्टीवन ए। लोवे

नहीं, यह तब भी ठीक वैसा ही है, जब मैंने अपनी टिप्पणी और SQL सर्वर के सभी संस्करणों में जो पुनरावर्ती CTE का समर्थन करता है। जैसा कि आपका लिंक कहता है "जब 0 निर्दिष्ट किया जाता है, तो कोई सीमा लागू नहीं होती है।"

— मार्टिन स्मिथ

Answer 1

कर्सर के साथ "ओवरहेड" केवल एपीआई का हिस्सा है। कर्सर हैं कि RDBMS के हिस्से हुड के नीचे कैसे काम करते हैं। अक्सर CREATE TABLEऔर INSERTहै SELECTबयान, और कार्यान्वयन स्पष्ट आंतरिक कर्सर कार्यान्वयन है।

उच्च-स्तरीय "सेट-आधारित ऑपरेटरों" का उपयोग करके कर्सर परिणामों को एकल परिणाम सेट में बंडल करता है, जिसका अर्थ है कि एपीआई कम आगे-पीछे।

प्रथम श्रेणी के संग्रह प्रदान करने वाले आधुनिक भाषाओं को कर्सर पूर्ववर्ती करते हैं। पुराने C, COBOL, फोरट्रान, आदि को एक समय में पंक्तियों को संसाधित करना पड़ता था क्योंकि "संग्रह" की कोई धारणा नहीं थी जिसका व्यापक रूप से उपयोग किया जा सकता था। जावा, C #, पायथन आदि में परिणाम सेट को शामिल करने के लिए प्रथम श्रेणी की सूची संरचनाएँ हैं।

धीमा मुद्दा

कुछ हलकों में, रिलेशनल जॉइन एक रहस्य है, और लोग एक साधारण जॉइन के बजाय नेस्टेड कोर्स लिखेंगे। मैंने वास्तव में महाकाव्य नेस्टेड लूप संचालन को बहुत सारे और बहुत सारे कर्सर के रूप में लिखा है। RDBMS अनुकूलन को हराना। और वास्तव में धीरे-धीरे चल रहा है।

सरल SQL, नेस्टेड कर्सर लूप को जॉन्स और एक सिंगल के साथ रिप्लेस करता है, फ्लैट कर्सर लूप कार्यक्रमों को 100 वें समय में चला सकता है। [उन्हें लगा कि मैं अनुकूलन का देवता हूं। मैंने जो कुछ किया था, वह नेस्टेड लूप को जोड़ के साथ बदल दिया गया था। अभी भी कर्सर का उपयोग किया जाता है।]

यह भ्रम अक्सर अभिशापों का एक संकेत होता है। हालाँकि, यह कर्सर नहीं है, यह कर्सर का दुरुपयोग है जो समस्या है।

आकार मुद्दा

वास्तव में महाकाव्य परिणाम सेट के लिए (यानी, एक फ़ाइल के लिए एक तालिका डंपिंग), कर्सर आवश्यक हैं। सेट-आधारित संचालन वास्तव में बड़े परिणाम सेट को मेमोरी में एकल संग्रह के रूप में सेट नहीं कर सकता है।

वैकल्पिक

मैं यथासंभव ओआरएम परत का उपयोग करने की कोशिश करता हूं। लेकिन इसके दो उद्देश्य हैं। सबसे पहले, कर्सर ORM घटक द्वारा प्रबंधित किए जाते हैं। दूसरा, SQL अनुप्रयोग से एक कॉन्फ़िगरेशन फ़ाइल में अलग किया गया है। ऐसा नहीं है कि शाप देने वाले बुरे हैं। यह है कि उन सभी को खोलने, बंद करने और लाने के लिए कोडिंग मूल्य-वर्धित प्रोग्रामिंग नहीं है।

Comments

"कर्सर हैं कि RDBMS हूड के तहत कैसे काम करता है।" यदि आप विशेष रूप से SQL सर्वर, ठीक है, ठीक है, मैं उस से अनभिज्ञ हूँ मतलब है। लेकिन मैंने कई RDBMS (और ORDBMS) (स्टोनब्रोकर के तहत) के इंटर्नल पर काम किया है और उनमें से किसी ने भी ऐसा नहीं किया है। उदा: आंतरिक रूप से टुपल्स के "परिणाम सेट" के लिए कौन सी मात्रा का उपयोग करता है।

— रिचर्ड टी

@ रीचर्ड टी: मैं आरडीबीएमएस स्रोत के बारे में दूसरे हाथ से काम कर रहा हूं; मैं बयान में संशोधन करूंगा।

— S.Lott

"मैंने वास्तव में महाकाव्य नेस्टेड लूप संचालन को बहुत सारे और बहुत सारे अभिशापों के रूप में लिखा है।" मैं उन्हें भी देखता रहता हूं। यह विश्वास करना कठिन है।

— रसेल एचएच

Answer 2

Cursors लोगों को पीढ़ी-दर-पीढ़ी पर्यावरण पर एक प्रक्रियात्मक मानसिकता लागू करते हैं।

और वे धीमी हैं !!!

से SQLTeam :

कृपया ध्यान दें कि SQL सर्वर के अंदर डेटा तक पहुँचने के लिए कर्सर सबसे कम रास्ता है। केवल तभी उपयोग किया जाना चाहिए जब आपको वास्तव में एक समय में एक पंक्ति तक पहुंचने की आवश्यकता हो। इसका एकमात्र कारण मैं इसके बारे में सोच सकता हूं कि प्रत्येक पंक्ति में एक संग्रहीत प्रक्रिया को कॉल करना है। में कर्सर प्रदर्शन लेख मुझे पता चला कि कर्सर हैं तीस से अधिक बार आधारित विकल्प सेट की तुलना में धीमी ।

Comments

यह लेख 7 साल पुराना है, क्या आपको लगता है कि इस बीच शायद चीजें बदल गई होंगी?

— स्टीवन ए। लोव

मुझे यह भी लगता है कि वास्तव में शाप देने वाले धीमे होते हैं और आमतौर पर इससे बचा जाता है। हालांकि, अगर ओपी उस सवाल का जिक्र कर रहा है जो मुझे लगता है कि वह था, तो एक कर्सर वहां सही समाधान था (मेमोरी की कमी के कारण एक बार रिकॉर्ड करना)।

— rmeador

अद्यतन लेख सापेक्ष गति माप को सही नहीं करता है, लेकिन यह कुछ अच्छे अनुकूलन और विकल्प प्रदान करता है। ध्यान दें कि मूल लेख कहता है कि लूप्स की तुलना में कर्सर 50 गुना अधिक तेज होते हैं, जो दिलचस्प है

— स्टीवन ए। लोव

@BoltBait: मैं व्यक्तिगत रूप से सोचता हूं कि यदि आप कंबल का दावा करते हैं कि आप वास्तव में 45 वर्ष के नहीं हो सकते हैं :-P

— स्टीवन ए। लोवे

@BoltBait: तुम बच्चे मेरे लॉन से निकल जाओ!

— स्टीवन ए लोव

Answer 3

ऊपर एक उत्तर है जो कहता है "कर्सर SQL सर्वर के अंदर डेटा तक पहुंचने का सबसे कम तरीका है ... कर्सर सेट आधारित विकल्पों की तुलना में तीस गुना अधिक धीमा हैं।"

यह कथन कई परिस्थितियों में सही हो सकता है, लेकिन एक कंबल बयान के रूप में यह समस्याग्रस्त है। उदाहरण के लिए, मैंने उन परिस्थितियों में कर्सर का अच्छा उपयोग किया है, जहां मैं एक बड़ी तालिका की कई पंक्तियों को प्रभावित करने वाले अपडेट या डिलीट ऑपरेशन को करना चाहता हूं, जो निरंतर उत्पादन रीड प्राप्त कर रहा है। एक संग्रहीत प्रक्रिया चलाने से जो एक समय में एक पंक्ति को अपडेट करती है, सेट-आधारित ऑपरेशनों की तुलना में तेज़ होती है, क्योंकि सेट-आधारित ऑपरेशन रीड ऑपरेशन के साथ संघर्ष करता है और अंत में भयानक लॉकिंग समस्याओं का कारण बनता है (और पूरी तरह से उत्पादन प्रणाली को मार सकता है,) गंभीर मामलों में)।

अन्य डेटाबेस गतिविधि की अनुपस्थिति में, सेट-आधारित संचालन सार्वभौमिक रूप से तेज होते हैं। उत्पादन प्रणालियों में, यह निर्भर करता है।

Comments

अपवाद की तरह लगता है जो नियम को साबित करता है।

— जोएल कोएहॉर्न

@ [जोएल कोएहॉर्न]: मैंने कभी यह नहीं समझा।

— स्टीवन ए लोव

@ [स्टीवन ए लोव] वाक्यांशों ..org.uk / meanings/ exception- that-proves-the-rule.html अपवाद को "क्या बचा है" के रूप में समझते हैं और ध्यान दें कि यहां नियम कुछ ऐसा है "अधिकांश स्थिति में अभिशाप हैं" खराब"।

— डेविड लेव

@delm: लिंक के लिए धन्यवाद, अब मैं वाक्यांश को और भी कम समझता हूँ!

— स्टीवन ए लोव

@ [स्टीवन ए। लोव] मूल रूप से यह कह रहा है कि यदि आप एक सबकेस के साथ "नियम को तोड़ते हैं", तो एक नियम को तोड़ने के लिए एक सामान्य नियम होना चाहिए, एक नियम मौजूद है। उदाहरण से लिंक: ("यदि हमारे पास 'रविवार को प्रवेश नि: शुल्क है' जैसा बयान है, तो हम यथोचित मान सकते हैं कि, एक सामान्य नियम के रूप में, प्रवेश के लिए शुल्क लिया गया है।")

— भूनें

Answer 4

उन जगहों पर SQL डेवलपर्स की शुरुआत करके कर्सर का उपयोग किया जाता है जहां सेट-आधारित संचालन बेहतर होगा। विशेष रूप से जब लोग एक पारंपरिक प्रोग्रामिंग भाषा सीखने के बाद एसक्यूएल सीखते हैं, तो "इन रिकॉर्ड्स पर पुनरावृति" मानसिकता लोगों को अनुचित तरीके से अभिशापों का उपयोग करने के लिए नेतृत्व करती है।

अधिकांश गंभीर एसक्यूएल पुस्तकों में एक अध्याय शामिल होता है, जिसमें श्राप देने वालों का उपयोग होता है; अच्छी तरह से लिखे गए लोग यह स्पष्ट करते हैं कि शाप देने वालों की अपनी जगह है, लेकिन इसका उपयोग सेट-आधारित संचालन के लिए नहीं किया जाना चाहिए।

स्पष्ट रूप से ऐसी स्थितियाँ हैं, जहाँ अभिशाप सही विकल्प हैं, या कम से कम एक सही विकल्प।

Answer 5

जब एक कर्सर विधि का उपयोग किया जाता है, तो अनुकूलनकर्ता समस्या को बदलने के लिए अक्सर रिलेशनल बीजगणित का उपयोग नहीं कर सकता है। अक्सर एक कर्सर एक समस्या को हल करने का एक शानदार तरीका है, लेकिन एसक्यूएल एक घोषणात्मक भाषा है, और डेटाबेस में बहुत सी जानकारी है, बाधाओं से लेकर आंकड़े और सूचकांक तक जिसका अर्थ है कि ऑप्टिमाइज़र के पास हल करने के लिए बहुत सारे विकल्प हैं। समस्या, जबकि एक कर्सर बहुत स्पष्ट रूप से समाधान का निर्देशन करता है।

Answer 6

Oracle PL / SQL कर्सर में टेबल लॉक नहीं होंगे और बल्क-कलेक्शन / बल्क-फ़िशिंग का उपयोग संभव है।

ओरेकल 10 में अक्सर इस्तेमाल किया जाने वाला कर्सर

  for x in (select ....) loop
    --do something 
  end loop;

एक बार में लगभग 100 पंक्तियाँ लाना। स्पष्ट बल्क-कलेक्शन / बल्क-भ्रूण भी संभव है।

हालाँकि, PL / SQL कर्सर एक अंतिम उपाय है, जब आप सेट-आधारित SQL के साथ किसी समस्या को हल करने में असमर्थ होते हैं, तो उनका उपयोग करें।

एक और कारण समानांतरकरण है, डेटाबेस के लिए पंक्ति-दर-पंक्ति अनिवार्य कोड की तुलना में बड़े सेट-आधारित बयानों को समानांतर करना आसान है। यही कारण है कि कार्यात्मक प्रोग्रामिंग अधिक से अधिक लोकप्रिय हो जाती है (हास्केल, एफ #, लिस्प, सी # LINQ, MapReduce ...), कार्यात्मक प्रोग्रामिंग समानांतरीकरण को आसान बनाता है। प्रति कंप्यूटर सीपीयू की संख्या बढ़ रही है इसलिए समानांतरकरण अधिक से अधिक एक मुद्दा बन जाता है।

Answer 7

सामान्य तौर पर, क्योंकि एक संबंधपरक डेटाबेस पर, कर्सर का उपयोग करने वाले कोड का प्रदर्शन सेट-आधारित संचालन की तुलना में बदतर परिमाण का क्रम है।

Comments

क्या आपके पास इसके लिए कोई बेंचमार्क या संदर्भ है? मैंने इस तरह के किसी भी कठोर प्रदर्शन में कमी नहीं देखी है ... लेकिन शायद मेरी तालिकाओं में इसके लिए पर्याप्त पंक्तियाँ नहीं हैं (एक मिलियन या उससे कम, आमतौर पर)?

— स्टीवन ए। लोव

ओह रुको मैं देख रहा हूं कि आपका क्या मतलब है - लेकिन मैं कभी भी सेट ऑपरेशन के अभिशापों का उपयोग करने की वकालत नहीं करूंगा, केवल शाप देने वालों से बचने के लिए चरम पर नहीं जाऊंगा

— स्टीवन ए लोवे

मुझे याद है पहली बार मैंने एसक्यूएल किया था, हमें एक मेनफ्रेम से SQL सर्वर डेटाबेस में 50k दैनिक डेटा फ़ाइल आयात करना था ... मैंने एक कर्सर का उपयोग किया, और पता चला, कि कर्सर का उपयोग करते हुए आयात में लगभग 26 घंटे लग रहे थे। जब मैं सेट-आधारित संचालन में बदल गया, तो प्रक्रिया में 20 मिनट लगे।

— चार्ल्स ब्रेटाना

Answer 8

ऊपर दिए गए उत्तरों ने लॉकिंग के महत्व पर जोर नहीं दिया है। मैं शाप देने वालों का बहुत बड़ा प्रशंसक नहीं हूं क्योंकि वे अक्सर टेबल स्तर के ताले लगाते हैं।

Comments

हाँ धन्यवाद! इसे रोकने के लिए विकल्पों के बिना (केवल पढ़ें, केवल आगे, आदि) वे निश्चित रूप से करेंगे, जैसा कि किसी भी (sql सर्वर) ऑपरेशन में होगा जो कई पंक्तियों और फिर कई पृष्ठों की पंक्तियों पर कब्जा करने के लिए आगे बढ़ता है।

— स्टीवन ए लोव

?? यह आपकी लॉकिंग स्ट्रैटेजी के साथ एक समस्या है, न कि कर्सर। यहां तक ​​कि एक सेलेक्ट स्टेटमेंट में रीड लॉक शामिल होंगे।

— एडम

Answer 9

यह मेरे लायक है कि मैंने पढ़ा है कि "एक" एक कर्सर बाहर सेट-आधारित समकक्ष प्रदर्शन करेगा एक चल कुल में है। एक छोटी सी मेज पर स्तंभों द्वारा क्रम पर पंक्तियों को समेटने की गति सेट-आधारित ऑपरेशन के पक्ष में होती है, लेकिन जैसे ही पंक्ति आकार में तालिका बढ़ती है, कर्सर तेज हो जाएगा, क्योंकि यह बस चल रहे कुल मान को अगले पास तक ले जा सकता है पाश। अब जहां आपको एक रनिंग टोटल करना चाहिए वह एक अलग तर्क है ...

Comments

यदि आपका मतलब किसी प्रकार (मिनट, अधिकतम, योग) का "कुल" चलाने से है, तो कोई भी सक्षम डीबीएमएस क्लाइंट-साइड, कर्सर आधारित समाधान से पैंट को हरा देगा, यदि केवल इसलिए कि इंजन में फ़ंक्शन किया जाता है और कोई क्लाइंट नहीं है <-> सर्वर ओवरहेड। शायद SQL सर्वर सक्षम नहीं है?

— रिचर्ड टी

@ [रिचर्ड टी]: हम सर्वर-साइड कर्सर की चर्चा कर रहे हैं, जैसे कि एक संग्रहीत प्रक्रिया के भीतर, क्लाइंट-साइड कर्सर नहीं; गलतफहमी के लिए खेद है!

— स्टीवन ए लोव

Answer 10

मैं इस पृष्ठ के लेख से सहमत हूँ:

http://weblogs.sqlteam.com/jeffs/archive/2008/06/05/sql-server-cursor-removal.aspx

Comments

अच्छा लेख; लेखक ने यह भी उल्लेख किया है कि जबकि-लूपर्स कम से कम कुशल होते हैं

— स्टीवन ए। लोव

Answer 11

प्रदर्शन (गैर) मुद्दों के बाहर, मुझे लगता है कि सबसे बड़ी असफलता अभिशापों की है, वे डिबग करने के लिए दर्दनाक हैं। विशेष रूप से अधिकांश क्लाइंट एप्लिकेशन में कोड की तुलना में जहां डिबगिंग तुलनात्मक रूप से आसान होती है और भाषा की विशेषताएं बहुत आसान हो जाती हैं। वास्तव में, मैं तर्क देता हूं कि कर्सर के साथ SQL में जो कुछ भी किया जा रहा है वह संभवतः क्लाइंट ऐप में पहली बार हो रहा होगा।

Comments

SQL डीबग करने के लिए दर्दनाक है, यहां तक ​​कि बिना कर्सर के भी। विज़ुअल स्टूडियो में MS SQL स्टेप-थ्रू टूल्स मुझे पसंद नहीं आते हैं (वे बहुत हैंग करते हैं, या बिल्कुल भी ब्रेकपॉइंट नहीं देते हैं), इसलिए मैं आमतौर पर PRINT स्टेटमेंट्स में कमी कर रहा हूं ;-)

— स्टीवन ए लोव

Answer 12

क्या आप उस कर्सर उदाहरण या प्रश्न के लिंक को पोस्ट कर सकते हैं? शायद एक पुनरावर्ती CTE की तुलना में एक बेहतर तरीका है।

अन्य टिप्पणियों के अलावा, अनुचित तरीके से इस्तेमाल किए जाने वाले कर्सर (जो अक्सर होता है) अनावश्यक पृष्ठ / पंक्ति ताले का कारण बनते हैं।

Comments

एक बेहतर तरीका है - एक सनकी 'कर्सर; ;-)

— स्टीवन ए। लोव

Answer 13

आप शायद दूसरे पैराग्राफ के बाद अपने प्रश्न का निष्कर्ष निकाल सकते थे, बजाय इसके कि लोगों को "पागल" कहा जाए, क्योंकि उनके पास एक अलग दृष्टिकोण है जो आप करते हैं और अन्यथा उन पेशेवरों का मजाक उड़ाने की कोशिश कर रहे हैं, जिनके पास ऐसा करने का बहुत अच्छा कारण हो सकता है।

जैसा कि आपके सवाल के अनुसार, निश्चित रूप से ऐसी स्थितियां हैं, जिनके लिए एक कर्सर को बुलाया जा सकता है, मेरे अनुभव में डेवलपर्स तय करते हैं कि एक कर्सर को "एफएआर" का अधिक बार उपयोग करना चाहिए वास्तव में मामला है। किसी के द्वारा गलत तरीके से बहुत अधिक उपयोग किए जाने के कारण, जहां वे अपनी राय में बहुत ऊंचे हैं, उनका उपयोग नहीं करते।

Comments

कृपया अधिक ध्यान से पढ़ें, टॉम - सटीक वाक्यांश "पागल घृणा" था; "नफरत" विशेषण "पागल" का उद्देश्य था, न कि "लोग"। अंग्रेजी कभी-कभी थोड़ी मुश्किल हो सकती है ;-)

— स्टीवन ए। लोव

Answer 14

बेसिकल 2 कोड के ब्लॉक जो एक ही काम करते हैं। शायद यह थोड़ा अजीब उदाहरण है लेकिन यह बात साबित करता है। SQL सर्वर 2005:

SELECT * INTO #temp FROM master..spt_values
DECLARE @startTime DATETIME

BEGIN TRAN 

SELECT @startTime = GETDATE()
UPDATE #temp
SET number = 0
select DATEDIFF(ms, @startTime, GETDATE())

ROLLBACK 

BEGIN TRAN 
DECLARE @name VARCHAR

DECLARE tempCursor CURSOR
    FOR SELECT name FROM #temp

OPEN tempCursor

FETCH NEXT FROM tempCursor 
INTO @name

SELECT @startTime = GETDATE()
WHILE @@FETCH_STATUS = 0
BEGIN

    UPDATE #temp SET number = 0 WHERE NAME = @name
    FETCH NEXT FROM tempCursor 
    INTO @name

END 
select DATEDIFF(ms, @startTime, GETDATE())
CLOSE tempCursor
DEALLOCATE tempCursor

ROLLBACK 
DROP TABLE #temp

एकल अद्यतन 156 एमएस लेता है, जबकि कर्सर 2016 एमएस लेता है।

Comments

अच्छी तरह से हाँ, यह इस बात को साबित करता है कि यह एक कर्सर का उपयोग करने का एक बहुत अच्छा तरीका है! लेकिन क्या होगा यदि प्रत्येक पंक्ति का अद्यतन तिथि क्रम में पूर्व पंक्ति के मूल्य पर निर्भर करता है?

— स्टीवन ए। लोव

BEGIN TRAN SELECT TOP 1 बेसल टेबल टेबल से ORDER द्वारा टाइमस्टैम्प DESC INSERT टेबल (फ़ील्ड्स) VALUES (वैल्यू, जिसमें पूर्व रिकॉर्ड से प्राप्त मूल्य शामिल है) COMMIT TRAN

— dkretz

@doofledorfer: जो कि दिनांक द्वारा अंतिम पंक्ति के आधार पर एक पंक्ति सम्मिलित करेगा, तिथि क्रम में इसकी पूर्व पंक्ति के मान से प्रत्येक पंक्ति को अपडेट नहीं करेगा

— स्टीवन ए। लोव

सही मायने में कर्सर का उपयोग करने के लिए आपको अपडेट में कहां का उपयोग करना चाहिए

— erikkallen