मेरा पहला विचार यहाँ है - प्रदर्शन समस्या क्या है? सुनिश्चित करें कि आपके पास लूप के भीतर एक लूप (प्रति पंक्ति एक बार जहां लागू करने के लिए) है कि यह एक क्वेरी चलाता है। लेकिन क्या आपको खराब निष्पादन योजनाएं मिल रही हैं? क्या आपका परिणाम बहुत बड़ा है? लेकिन आइए जेनेरिक की ओर मुड़ें। एक बार इस समस्या को कैसे हल करता है? एसक्यूएल वास्तव में ज्ञापन नहीं करता है (जैसा कि शानदार @Martin_Smith बताते हैं)। तो लड़का क्या करे?
विकल्प 1 - नया डिज़ाइन
बिल्कुल नया डिज़ाइन बनाएं। इस विशिष्ट मामले में @Aaron_Bertrand बताता है कि एक कैलेंडर तालिका आपकी आवश्यकताओं को पूरा कर सकती है। बिलकुल सही। यह वास्तव में आपको गैर कैलेंडर स्थितियों में मदद नहीं करता है, लेकिन जैसा कि अक्सर SQL में होता है, आपको थोड़ा अलग सोचने की आवश्यकता है।
विकल्प 2 - UDF को कम कहें
इस फ़ंक्शन को कॉल करने वाले आइटम के सेट को संक्षिप्त करें। यह मुझे बहुत कुछ याद दिलाता है कि कैसे सफल हो उपयोग-पंक्ति-संख्या/4383164#4383164">पेजिंग/पंक्ति गिनती . एक छोटा परिणाम सेट उत्पन्न करें जिसमें आवश्यक विशिष्ट मान हों और फिर अपने यूडीएफ को कॉल करें ताकि इसे केवल कुछ ही बार बुलाया जा सके। यह एक विकल्प हो भी सकता है और नहीं भी, लेकिन कई परिदृश्यों में काम कर सकता है।
विकल्प 3 - गतिशील UDF
मैं शायद इस सुझाव के लिए कमरे से बाहर निकल जाऊंगा, लेकिन यहाँ जाता है। इस यूडीएफ को जो धीमा बनाता है वह है लूप के अंदर चयन कथन। यदि आपकी हॉलिडे टेबल वास्तव में बार-बार बदलती है तो आप टेबल पर ट्रिगर लगा सकते हैं। ट्रिगर यूडीएफ को लिखेगा और अपडेट करेगा। नया यूडीएफ छुट्टियों के सभी फैसलों को लागू कर सकता है। एसक्यूएल लेखन एसक्यूएल के साथ क्या यह नरभक्षण की तरह थोड़ा सा होगा? ज़रूर। लेकिन यह सब-क्वेरी से छुटकारा दिलाएगा और यूडीएफ को गति देगा। हेकलिंग शुरू होने दें।
विकल्प 4 - इसे याद रखें!
जबकि SQL सीधे याद नहीं कर सकता है, हमारे पास SQL CLR है। UDF को SQL CLR udf में बदलें। सीएलआर में आपको स्टैटिक वेरिएबल्स का उपयोग करने को मिलता है। आप कुछ नियमित अंतराल पर छुट्टियों की तालिका को आसानी से पकड़ सकते हैं और उन्हें हैशटेबल में स्टोर कर सकते हैं। फिर सीएलआर में अपने लूप को फिर से लिखें। आप और भी आगे जा सकते हैं और पूरे उत्तर को याद कर सकते हैं यदि यह उचित तर्क है।
अपडेट करें:
विकल्प 1 - मैं वास्तव में यहाँ सामान्य पर ध्यान केंद्रित करने की कोशिश कर रहा था, न कि आपके द्वारा ऊपर उपयोग किए गए उदाहरण फ़ंक्शन पर। हालाँकि, आपके UDF का वर्तमान डिज़ाइन हॉलिडे टेबल पर कई कॉल की अनुमति देता है यदि आप एक पंक्ति में कुछ हिट करते हैं। किसी प्रकार की कैलेंडर-शैली-तालिका का उपयोग करना जिसमें 'बुरे दिनों' और संबंधित 'अगले व्यावसायिक दिन' की सूची शामिल है, आपको कई हिट और क्वेरी की संभावना को दूर करने की अनुमति देगा।
विकल्प 3 - जबकि डोमेन समय से पहले अज्ञात है, आप अपनी अवकाश तालिका को बहुत अच्छी तरह से संशोधित कर सकते हैं। किसी दिए गए अवकाश दिवस के लिए इसमें अगला संगत कार्य दिवस होगा। इस डेटा से आप नीचे एक लंबे केस स्टेटमेंट (जब '5/5/2012' फिर '5/14/2012' या कुछ इसी तरह) के साथ एक यूडीएफ थूक सकते हैं। यह रणनीति हर प्रकार की समस्या के लिए काम नहीं कर सकती है, लेकिन कुछ प्रकार की समस्याओं के लिए अच्छी तरह से काम कर सकती है।
विकल्प 4 - हर तकनीक के निहितार्थ होते हैं। सीएलआर को तैनात करने की जरूरत है, एसक्यूएल सर्वर कॉन्फ़िगरेशन संशोधित किया गया है और एसक्यूएल सीएलआर 3.5 ढांचे तक सीमित है। व्यक्तिगत रूप से, मैंने इन समायोजनों को काफी आसान पाया है, लेकिन आपकी स्थिति अलग हो सकती है (एक अड़ियल डीबीए कहें, या उत्पादन सर्वर में संशोधन पर प्रतिबंध)।
स्थिर चर का उपयोग करने के लिए असेंबली की आवश्यकता होती है be पूरा भरोसा दिया . आपको यह सुनिश्चित करना होगा कि आपने अपना लॉकिंग सही किया है।
