इनलाइन SQL बनाम संग्रहीत कार्यविधियाँ


27

मुझे पता है कि संग्रहीत प्रक्रिया निष्पादन पथ (अनुप्रयोगों में इनलाइन sql की तुलना में) के माध्यम से अधिक कुशल हैं। हालांकि, जब दबाया जाता है, तो मैं सुपर डेलीगेट नहीं हूं कि क्यों।

मैं इसके लिए तकनीकी तर्क जानना चाहता हूं (एक तरह से जिसे मैं बाद में किसी को समझा सकता हूं)।

क्या कोई मुझे एक अच्छा जवाब तैयार करने में मदद कर सकता है?


1
एक ठीक से पैराट्राइज्ड क्वेरी , प्रदर्शन के दृष्टिकोण से, संग्रहीत कार्यविधि जितनी ही अच्छी है। दोनों पहले उपयोग से पहले संकलित हो जाते हैं, दोनों बाद के निष्पादन पर कैश्ड निष्पादन योजना का पुन: उपयोग करेंगे, दोनों योजनाएं एक ही योजना कैश में संग्रहीत हो जाती हैं और दोनों एक ही नाम को संभाल लेंगे। SQL सर्वर में आज संग्रहीत कार्यविधि के लिए कोई प्रदर्शन लाभ नहीं है।
marc_s

यदि प्रश्न समान हैं तो @marc_s यह सच है। हालाँकि जैसा कि मैंने अपने उत्तर में बताया कि तदर्थ प्रश्नों की कुछ विशेषताएँ हैं जो समान प्रतीत होने वाले प्रश्नों के लिए भी प्रदर्शन की समस्या हो सकती हैं।
हारून बर्ट्रेंड

जवाबों:


42

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

मैं अभी भी निम्नलिखित कारणों के लिए डीबीए की ओर से संग्रहीत प्रक्रियाओं को पसंद करता हूं (और उनमें से कई प्रदर्शन पर भारी प्रभाव डाल सकते हैं):

  • यदि मेरे पास एक से अधिक क्वेरीज़ हैं, जो एक ही क्वेरीज़ का पुनः उपयोग करते हैं, तो एक संग्रहीत कार्यविधि अलग-अलग कोडबेस में एक ही बार में एक ही तदर्थ क्वेरी को लिटाने की बजाय, उस तर्क को कूटबद्ध करती है। एक ही क्वेरी का पुनः उपयोग करने वाले एप्लिकेशन भी कैश ब्लोट की योजना के अधीन हो सकते हैं, जब तक कि उन्हें वर्बेटिम कॉपी नहीं किया जाता है। यहां तक ​​कि मामले में अंतर और सफेद स्थान एक ही योजना के कई संस्करणों को संग्रहीत (बेकार) कर सकते हैं।
  • मैं आवेदन स्रोत कोड तक पहुँच के बिना या क्वेरी क्या कर रहा हूँ, यह देखने के लिए महंगे निशान चलाने के बिना क्या कर रहा है, इसका निरीक्षण और निवारण कर सकता हूँ।
  • मैं यह भी नियंत्रित कर सकता हूं (और पहले से जान सकता हूं) कि कौन-सी क्वेरी चल सकती है, कौन-सी तालिकाएँ इसे एक्सेस कर सकती हैं और किस संदर्भ में, आदि। यदि डेवलपर्स अपने आवेदन में ऐड-हॉक क्वेरी लिख रहे हैं, तो उन्हें या तो जाना होगा हर बार मेरी शर्ट की आस्तीन को टंग करें ताकि उन्हें उस मेज तक पहुंच की आवश्यकता हो, जिसके बारे में मुझे पता नहीं था या मैं भविष्यवाणी नहीं कर सकता था, या अगर मैं कम जिम्मेदार / उत्साही और / या सुरक्षा-सचेत हूं, तो मैं इसे बढ़ावा देने जा रहा हूं उपयोगकर्ता dbo करने के लिए तो वे मुझे गुस्सा करना बंद करो। आमतौर पर ऐसा तब किया जाता है जब डेवलपर्स डीबीए या डीबीए को अलग कर देते हैं। वह अंतिम बिंदु हमारा बुरा है, और हमें आपके द्वारा आवश्यक प्रश्नों को प्रदान करने के बारे में बेहतर होना चाहिए।
  • संबंधित नोट पर, संग्रहीत कार्यविधियों का एक सेट, सूची के लिए एक बहुत ही आसान तरीका है कि मेरे सिस्टम पर क्या प्रश्न हो सकते हैं। जैसे ही किसी एप्लिकेशन को प्रक्रियाओं को बायपास करने और अपने स्वयं के तदर्थ प्रश्नों को सबमिट करने की अनुमति मिलती है, उन्हें खोजने के लिए, मुझे एक ट्रेस चलाना होगा जो एक संपूर्ण व्यापार चक्र को कवर करता है, या आवेदन कोड के सभी के माध्यम से पार्स करता है (फिर से, क्वेरी की तरह दिखने वाली किसी भी चीज़ को खोजने के लिए मेरे पास पहुंच नहीं हो सकती है)। संग्रहीत प्रक्रियाओं की सूची को देखने में सक्षम होना (और sys.sql_modulesविशिष्ट वस्तुओं के संदर्भ के लिए एक स्रोत को पकड़ना ), हर किसी के जीवन को बहुत आसान बना देता है।
  • मैं SQL इंजेक्शन को रोकने के लिए बहुत अधिक लंबाई तक जा सकता हूं; यहां तक ​​कि अगर मैं इनपुट लेता हूं और इसे गतिशील एसक्यूएल के साथ निष्पादित करता हूं, तो मैं बहुत कुछ नियंत्रित कर सकता हूं जो होने की अनुमति है। इनलाइन SQL स्टेटमेंट बनाते समय डेवलपर क्या कर रहा है, इस पर मेरा कोई नियंत्रण नहीं है।
  • मैं आवेदन स्रोत कोड तक पहुंच के बिना क्वेरी (या क्वेरीज़) का अनुकूलन कर सकता हूं, परिवर्तन करने की क्षमता, आवेदन की भाषा का ज्ञान इतनी प्रभावी ढंग से करने के लिए, प्राधिकरण (कभी भी परेशानी नहीं) को फिर से संकलित करने और फिर से तैनात करने के लिए एप्लिकेशन, आदि। यह विशेष रूप से समस्याग्रस्त है अगर ऐप वितरित किया गया है।
  • मैं SSMS में तेजी से आवेदन में कुछ धीमी गति के अधीन होने से अलग-अलग प्रश्नों से बचने के लिए संग्रहीत कार्यविधि के भीतर कुछ निश्चित विकल्पों को बाध्य कर सकता हूं ? समस्या का। इसका मतलब है कि दो अलग-अलग अनुप्रयोगों के लिए एक तदर्थ क्वेरी, एक हो सकता है SET ANSI_WARNINGS ON, और दूसरा हो सकता है SET ANSI_WARNINGS OFF, और वे प्रत्येक योजना की अपनी प्रति होगी। उन्हें मिलने वाली योजना उपयोग में मापदंडों, जगह में आँकड़े आदि पर निर्भर करती है, पहली बार क्वेरी को प्रत्येक मामले में कहा जाता है, जिससे विभिन्न योजनाएं बन सकती हैं और इसलिए बहुत अलग प्रदर्शन होता है।
  • मैं डेटा प्रकारों और कुछ मापदंडों का उपयोग कैसे नियंत्रित कर सकता हूं, कुछ ओआरएम के विपरीत - ईएफ जैसी चीजों के कुछ पुराने संस्करण एक पैरामीटर की लंबाई के आधार पर एक क्वेरी को पैरामीटर बनाएंगे, इसलिए यदि मेरे पास एक पैरामीटर एन'स्मिथ 'और दूसरा एन' जॉनसन 'मुझे योजना के दो अलग-अलग संस्करण मिलेंगे। उन्होंने यह तय कर दिया है। उन्होंने यह तय कर लिया है, लेकिन क्या अभी भी टूट गया है?
  • मैं ऐसी चीजें कर सकता हूं जो ओआरएम और अन्य "सहायक" फ्रेमवर्क और लाइब्रेरी अभी तक समर्थन करने में सक्षम नहीं हैं।

यह सब कहा, इस सवाल से तकनीकी बहस की तुलना में अधिक धार्मिक तर्कों को छेड़ने की संभावना है। अगर हम देखते हैं कि हो रहा है तो हम इसे बंद कर देंगे।


2
संग्रहीत प्रक्रियाओं का एक और कारण? लंबे समय तक, जटिल प्रश्नों के लिए, आपको हर बार सर्वर पर क्वेरी को धक्का देना होगा, जब तक कि यह एक स्पोक नहीं है, तो आप मूल रूप से "निष्पादित स्प्रोनेम" और कुछ मापदंडों को आगे बढ़ा रहे हैं। यह धीमे (या व्यस्त) नेटवर्क पर फर्क कर सकता है।
डेविड क्रोवेल

0

जबकि मैं प्रस्तुतकर्ता का सम्मान करता हूं, मैं प्रदान किए गए उत्तर से असहमत हूं और "धार्मिक कारणों" के लिए नहीं। दूसरे शब्दों में, मेरा मानना ​​है कि Microsoft ने ऐसी कोई सुविधा नहीं दी है जो संग्रहीत प्रक्रियाओं का उपयोग करने के लिए मार्गदर्शन की आवश्यकता को कम करती है।

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

मुझे लगता है कि एसपीआरओसी का उपयोग करने के सवाल का सरल जवाब है, जैसा कि प्रस्तुतकर्ता ने कहा: एसपीआरआरसी पार्स, अनुकूलित और संकलित हैं। जैसे, उनकी क्वेरी / निष्पादन योजनाएँ कैश की जाती हैं क्योंकि आपने किसी क्वेरी के स्थिर प्रतिनिधित्व को सहेज लिया है और आप, सामान्य रूप से, इसे केवल मापदंडों द्वारा अलग-अलग करेंगे, जो कॉपी किए गए / चिपकाए गए एसक्यूएल स्टेटमेंट के मामले में सही नहीं है, जो मॉर्फ्ड है पृष्ठ-दर-पृष्ठ और घटक / स्तरीय, और अक्सर इस हद तक परिवर्तनशील होते हैं कि विभिन्न तालिकाओं, यहां तक ​​कि डेटाबेस के नामों को कॉल-टू-कॉल से निर्दिष्ट किया जा सकता है। इस प्रकार के गतिशील तदर्थ के लिए अनुमति देनाएसक्यूएल सबमिशन, डीबी इंजन की संभावना को बहुत ही सख्त नियमों के अनुसार, अपने तदर्थ वक्तव्यों के लिए क्वेरी प्लान को फिर से उपयोग करने की संभावना को कम करता है। यहाँ, मैं डायनामिक एड हॉक क्वेश्चंस (उठाए गए प्रश्न की भावना में) बनाम कुशल सिस्टम SPROC sp_executesql के उपयोग के बीच अंतर कर रहा हूं।

अधिक विशेष रूप से, निम्नलिखित घटक हैं:

  • सीरियल और समानांतर क्वेरी योजना जो उपयोगकर्ता के संदर्भ को नहीं रखती है और DB इंजन द्वारा पुन: उपयोग करने की अनुमति देती है।
  • निष्पादन संदर्भ जो अलग-अलग डेटा मापदंडों के साथ एक नए उपयोगकर्ता द्वारा क्वेरी योजना के पुन: उपयोग के लिए अनुमति देता है।
  • प्रक्रिया कैश जो डीबी इंजन प्रश्न पूछती है ताकि हम जो क्षमता चाहते हैं उसे बना सकें।

जब एक SQL कथन एक वेब पेज से जारी किया जाता है, जिसे "तदर्थ कथन" कहा जाता है, तो इंजन अनुरोध को संभालने के लिए मौजूदा निष्पादन योजना की तलाश करता है। क्योंकि यह एक उपयोगकर्ता से प्रस्तुत किया गया पाठ है, इसे मान्य, पार्स, संकलित और निष्पादित किया जाएगा, यदि यह मान्य है। इस समय इसे शून्य की क्वेरी लागत प्राप्त होगी। क्वेरी लागत का उपयोग तब किया जाता है जब डीबी इंजन अपने एल्गोरिथ्म का उपयोग यह निर्धारित करने के लिए करता है कि कौन सी निष्पादन योजना कैश से बेदखल करने की योजना है।

डिफ़ॉल्ट रूप से, तदर्थ प्रश्नों को शून्य का मूल क्वेरी मूल्य मान प्राप्त होता है। किसी अन्य उपयोगकर्ता प्रक्रिया (या एक ही) द्वारा सटीक उसी तदर्थ क्वेरी पाठ के बाद के निष्पादन पर, वर्तमान क्वेरी लागत मूल संकलन लागत पर रीसेट हो जाती है। चूंकि हमारी तदर्थ क्वेरी का संकलन लागत शून्य है, इसलिए पुन: उपयोग की संभावना के लिए यह अच्छी तरह से नहीं है। जाहिर है, शून्य न्यूनतम-मूल्यवान पूर्णांक है, लेकिन इसे क्यों निकाला जाएगा?

जब मेमोरी दबाव उत्पन्न होता है, और वे यदि आपके पास अक्सर उपयोग की जाने वाली साइट होती है, तो डीबी इंजन एक क्लीनअप एल्गोरिदम का उपयोग करता है यह निर्धारित करने के लिए कि यह कैसे मेमोरी को पुनः प्राप्त कर सकता है जो कि प्रोसीजर कैश का उपयोग कर रहा है। यह वर्तमान क्वेरी लागत का उपयोग करता है यह तय करने के लिए कि कौन सी योजना को बेदखल करना है। जैसा कि आप अनुमान लगा सकते हैं, शून्य की लागत वाली योजनाएं पहले कैश से बेदखल हैं क्योंकि शून्य का अनिवार्य रूप से "इस योजना का कोई वर्तमान उपयोगकर्ता, या संदर्भ नहीं" है।

  • नोट: तदर्थ निष्पादन योजना - योजना की मूल संकलन लागत द्वारा प्रत्येक उपयोगकर्ता प्रक्रिया द्वारा वर्तमान लागत में वृद्धि की जाती है। हालाँकि, किसी भी योजना की अधिकतम लागत उसकी मूल संकलित लागत से अधिक नहीं हो सकती ... तदर्थ प्रश्नों के मामले में ... शून्य। तो, उस मूल्य से इसे "बढ़ाया" जाएगा ... शून्य - जिसका अनिवार्य रूप से मतलब है कि यह सबसे कम लागत की योजना बना रहेगा।

इसलिए, यह पूरी संभावना है कि इस तरह की योजना को पहली बार तब निकाला जाएगा जब मेमोरी दबाव उत्पन्न होता है।

इसलिए, यदि आपके पास बहुत सारी मेमोरी के साथ सर्वर बिल्ड-आउट "आपकी आवश्यकताओं से परे" है, तो आप इस समस्या को अक्सर एक व्यस्त सर्वर के रूप में अनुभव नहीं कर सकते हैं जिसमें केवल "पर्याप्त" मेमोरी है जो इसके कार्यभार को संभालने के लिए है। (क्षमा करें, सर्वर मेमोरी क्षमता और उपयोग कुछ व्यक्तिपरक / सापेक्ष हैं, हालांकि एल्गोरिथ्म नहीं है।)

अब, यदि मैं तथ्यात्मक रूप से एक या अधिक बिंदुओं के बारे में गलत हूं, तो मैं निश्चित रूप से सही होने के लिए खुला हूं।

अंत में, लेखक ने लिखा:

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

मेरा मानना ​​है कि लेखक "तदर्थ वर्कलोड के लिए अनुकूलन" विकल्प का उल्लेख कर रहा है।

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

हालाँकि, आपको यह विकल्प चालू करना होगा, क्योंकि यह डिफ़ॉल्ट रूप से बंद है।

अंत में, मैं इस बात पर जोर देना चाहता हूं कि, अक्सर, बहुत ही कारण डेवलपर्स SQL ​​को पृष्ठों, घटकों और अन्य स्थानों में एम्बेड करेंगे, ऐसा इसलिए है क्योंकि वे लचीला होना चाहते हैं और गतिशील SQL क्वेरी को डेटाबेस इंजन में जमा करते हैं। इसलिए, एक वास्तविक दुनिया उपयोग के मामले में, बहुत ही पाठ, कॉल-ओवर-कॉल सबमिट करना, होने की संभावना नहीं है क्योंकि हम SQL सर्वर पर तदर्थ प्रश्नों को सबमिट करते समय कैशिंग / क्षमताएँ प्राप्त करते हैं।

अतिरिक्त जानकारी के लिए, कृपया देखें:

https://technet.microsoft.com/en-us/library/ms181055(v=sql.105).aspx
http://sqlmag.com/database-performance-tuning/don-t-dyear-dynamic-sql

सबसे अच्छा,
हेनरी


4
मैंने आपकी पोस्ट के कई पैराग्राफ को ध्यान से, दो या तीन बार पढ़ा है, और मुझे अभी भी पता नहीं है कि आप क्या विचार व्यक्त करने का प्रयास कर रहे हैं। कुछ मामलों में आप वाक्यों के अंत में प्रकट होते हैं जो यह कहते हैं कि वाक्य कहने का प्रयास शुरू किया गया था। आपको वास्तव में इस सबमिशन को सावधानीपूर्वक संपादित करने और संपादित करने की आवश्यकता है।
पीटर जार्जेंस

प्रतिक्रिया पीटर के लिए धन्यवाद। यदि यह मामला है, तो संभव है कि मैं इस बिंदु को स्पष्ट करने के लिए अपने वाक्यों को छोटा कर दूं। क्या आप कृपया एक उदाहरण प्रदान कर सकते हैं कि मैं मूल विचार के विपरीत कहां दिखाई देता हूं? बहुत सराहना की।
हेनरी

नहीं, मेरा मतलब एड हॉक वर्कलोड के लिए ऑप्टिमाइज़ करने का नहीं था, मेरा मतलब स्टेटमेंट-लेवल ऑप्टिमाइज़ेशन से था। SQL सर्वर 2000 में, उदाहरण के लिए, एक संग्रहीत प्रक्रिया को एक पूरे के रूप में संकलित किया जाएगा, इसलिए एप्लिकेशन के पास अपने स्वयं के तदर्थ क्वेरी के लिए एक योजना का पुन: उपयोग करने का कोई तरीका नहीं था जो प्रक्रिया में कुछ से मिलान करने के लिए हुआ था। मैं कहूंगा कि मैं पीटर के साथ सहमत हूं - बहुत सारी चीजें जो आप कहते हैं, उनका पालन करना मुश्किल है। चीजें जैसे "मेरा मानना ​​है कि Microsoft द्वारा प्रदान की गई कोई सुविधा नहीं है जो संग्रहीत प्रक्रियाओं का उपयोग करने के लिए मार्गदर्शन की आवश्यकता कम हो जाती है।" अनावश्यक रूप से जटिल हैं और समझने के लिए बहुत अधिक मार्ग की आवश्यकता है। IMHO।
हारून बर्ट्रेंड

1
ऐसा लगता है कि "तदर्थ" एसक्यूएल के लिए आपका फैलाव इस विचार पर आधारित है कि एसक्यूएल किसी भी तरह निष्पादन के बीच बदल रहा है ... यह पूरी तरह से असत्य है जब पैरामीटर शामिल है।
b_levitt

0

TLDR: जब तक आपका इनलाइन sql पैरामीटरीकृत नहीं हो जाता तब तक दोनों के बीच कोई सराहनीय प्रदर्शन अंतर नहीं है।

ये कारण हैं कि मैंने धीरे-धीरे संग्रहीत प्रक्रियाओं को चरणबद्ध किया है:

  • हम एक 'बीटा' अनुप्रयोग वातावरण चलाते हैं - उत्पादन के समानांतर एक वातावरण जो उत्पादन डेटाबेस को साझा करता है। क्योंकि, db कोड अनुप्रयोग स्तर पर है और db संरचना परिवर्तन दुर्लभ हैं, हम लोगों को QA से परे नई कार्यक्षमता की पुष्टि करने और उत्पादन परिनियोजन विंडो के बाहर तैनाती करने की अनुमति दे सकते हैं लेकिन फिर भी उत्पादन कार्यक्षमता और गैर-महत्वपूर्ण सुधार प्रदान करते हैं। यह संभव नहीं होगा यदि आवेदन कोड का आधा हिस्सा डीबी में होता।

  • हम डेटाबेस स्तर (ऑक्टोपस + dacpacs) पर अभ्यास करते हैं। हालांकि, जबकि व्यापार परत और ऊपर मूल रूप से शुद्ध किया जा सकता है और प्रतिस्थापित किया जा सकता है और रिकवरी सिर्फ रिवर्स हो सकती है, जो कि वृद्धिशील और संभावित विनाशकारी परिवर्तनों के लिए सही नहीं है जो डेटाबेस में जाना चाहिए। नतीजतन, हम अपने DB तैनाती को हल्का और कम लगातार रखना पसंद करते हैं।

  • वैकल्पिक मापदंडों के लिए एक ही कोड की सटीक प्रतियों के पास से बचने के लिए, हम अक्सर 'जहाँ @ null या @ var = table.field' पैटर्न का उपयोग करेंगे। एक संग्रहीत खरीद के साथ, आपको अलग-अलग इरादों के बावजूद एक ही निष्पादन योजना प्राप्त करने की संभावना है, और इस तरह या तो प्रदर्शन की समस्याओं का अनुभव होता है या 'पुनर्नवीनीकरण' के संकेत के साथ कैश्ड योजनाओं को समाप्त करना है। हालाँकि, कोड के एक सरल बिट के साथ जो कि sql के अंत में एक "हस्ताक्षर" टिप्पणी करता है, हम विभिन्न योजनाओं को बाध्य कर सकते हैं जिनके आधार पर चर शून्य थे (सभी चर संयोजनों के लिए एक अलग योजना के रूप में व्याख्या नहीं की जा सकती - केवल शून्य बनाम अशक्त नहीं)।

  • मैं मक्खी के लिए केवल छोटे बदलाव के साथ परिणामों में नाटकीय परिवर्तन कर सकता हूं। उदाहरण के लिए, मेरे पास एक बयान हो सकता है जो दो सीटीई, "रॉ" और "रिपोर्टरीडी" के साथ बंद हो जाता है। ऐसा कुछ भी नहीं है जो कहता है कि दोनों सीटीई का इस्तेमाल किया जाना चाहिए।

    ...

    {(प्रारूप)} से * चुनें "

यह मुझे एक सुव्यवस्थित एपीआई कॉल और एक रिपोर्ट के लिए सटीक समान व्यापार तर्क पद्धति का उपयोग करने की अनुमति देता है और यह सुनिश्चित करने के लिए अधिक विस्तृत होना चाहिए कि मैं जटिल तर्क की नकल नहीं करता हूं।

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

Procs का उपयोग करने के लिए वैध कारण हैं:

  • सिक्योरिटी - आपको यहां एक और लेयर मिली है कि ऐप को जरूर जाना चाहिए। यदि एप्लिकेशन सेवा खाते को तालिकाओं को छूने की अनुमति नहीं है, लेकिन केवल procs पर 'निष्पादित' अनुमति है, तो आपको कुछ अतिरिक्त सुरक्षा मिली है। यह एक दिया नहीं है क्योंकि यह एक लागत है, लेकिन यह एक संभावना है।

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

कुछ ऐसे तर्क हैं जो वास्तव में प्रोक्स का समर्थन नहीं करते हैं या आसानी से कम हो जाते हैं IMO:

  • पुन: उपयोग - मैंने इसे "प्लस" के रूप में ऊपर उल्लेख किया है, लेकिन यहां यह भी उल्लेख करना चाहता है कि पुन: उपयोग बड़े पैमाने पर व्यावसायिक स्तर पर होना चाहिए। रिकॉर्ड डालने के लिए एक खरीद को "पुन: प्रयोज्य" नहीं माना जाना चाहिए जब व्यवसाय की परत अन्य गैर-डीबी सेवाओं की जांच कर रही हो।

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

  • कथन का आकार - खरीद नाम पर sql कथनों का एक अतिरिक्त kb आम तौर पर वापस आने वाले डेटा के सापेक्ष नगण्य होने वाला है। यदि यह संस्थाओं के लिए ठीक है, तो मेरे लिए ठीक है।

  • सटीक क्वेरी देखना - प्रश्नों को कोड में खोजना आसान है क्योंकि कोड में टिप्पणी के रूप में कॉलिंग स्थान को जोड़ना उतना ही सरल है। कोड को c # कोड से ssms में कॉपी करना आसान है क्योंकि कुछ रचनात्मक प्रक्षेप और टिप्पणी उपयोग आसान है:

        //Usage /*{SSMSOnly_}*/Pure Sql To run in SSMS/*{_SSMSOnly}*/
        const string SSMSOnly_ = "*//*<SSMSOnly>/*";
        const string _SSMSOnly = "*/</SSMSOnly>";
        //Usage /*{NetOnly_}{InterpolationVariable}{_NetOnly}*/
        const string NetOnly_ = "*/";
        const string _NetOnly = "/*";
    
  • Sql Injection - अपने प्रश्नों को परिमित करें। किया हुआ। यह वास्तव में पूर्ववत हो सकता है यदि खरीद गतिशील sql का उपयोग करने के बजाय है।

  • तैनाती को दरकिनार करते हुए - हम डेटाबेस स्तर पर भी अभ्यास करते हैं, इसलिए यह हमारे लिए कोई विकल्प नहीं है।

  • "आवेदन में धीमे, SSMS में तेज" - यह एक योजना कैशिंग समस्या है जो दोनों पक्षों को प्रभावित करती है। सेट विकल्प केवल एक नई योजना को संकलित करने का कारण बनता है जो कि वन सेट ऑफ चर के लिए समस्या को ठीक करने के लिए प्रकट होता है। यह केवल यही जवाब देता है कि आप अलग-अलग परिणाम क्यों देखते हैं - सेट विकल्प स्वयं ही सूँघने के मापदंडों की समस्या को ठीक नहीं करते हैं।

  • इनलाइन एसक्यूएल निष्पादन योजनाओं को कैश नहीं किया जाता है - बस गलत है। एक मानकीकृत कथन, जैसे कि खरीद नाम जल्दी से हैशेड है और फिर उस हैश द्वारा एक योजना की खोज की जाती है। यह 100% समान है।

  • स्पष्ट होने के लिए मैं कच्चे इनलाइन के बारे में बात कर रहा हूं एक ओआरएम से कोड उत्पन्न नहीं हुआ - हम केवल डैपर का उपयोग करते हैं जो सबसे अच्छा माइक्रो ओआरएम है।

https://weblogs.asp.net/fbouma/38178

/programming//a/15277/852208

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.