शायद यह समझ में आता है, सवाल को चारों ओर मोड़ने और usecases खोजने के लिए जहां केवल संग्रहीत प्रक्रियाएं कर सकती थीं , आप क्या हासिल करना चाहते हैं। शायद वास्तव में उपयोग के मामले हैं, जहां संग्रहीत प्रक्रियाएं बाहर खड़ी हैं।
अगर इससे कोई फर्क पड़ता है, तो मैं MSSQL और Entity फ्रेमवर्क का उपयोग कर रहा हूं।
एफई पर मेरे ज्ञान सीमित है, लेकिन जहाँ तक मैं देख सकते हैं, एफई (है बस ) किसी भी अन्य की तरह एक ORM; और सौभाग्य से उपयोग करने में सक्षम है कच्चे SQL ।
अगर मैं आपके दो प्रमुख बिंदु ले लूँ:
एक जटिल रिपोर्ट जिसे चलने में मिनट लग रहे थे (यह एक वेब ऐप में एक पेज था)। मैंने पाया कि मैं SQL लिख सकता हूं जो LINQ प्रदान करने की तुलना में बहुत अधिक कुशल था (केवल सेकंड चलने के लिए)।
एक रिपोर्ट करते समय LINQ / EF कम पड़ रहा था। और जैसा कि आपने देखा, SQLORM का उपयोग करने की तुलना में अधिक तेज़ था । लेकिन यह केवल संग्रहीत प्रक्रियाओं के पक्ष में या केवल बोलता है सब कुछ के लिए ओआरएम का उपयोग करने के खिलाफ है ?
आपकी समस्या स्पष्ट रूप से SQL के साथ हल हो सकती है । यदि वह क्वेरी संग्रहीत थी और आपके कोडबेस में नियंत्रित संस्करण - आपके उदाहरण के अनुसार - कम से कम कोई अंतर नहीं है ।
एक वेब एप्लिकेशन को एक अलग डेटाबेस पर कुछ तालिकाओं को पढ़ने और लिखने की आवश्यकता होती है जिसमें बहुत सारी अन्य, संवेदनशील जानकारी होती है जो एप्लिकेशन के लिए अप्रासंगिक थी। इसे हर चीज तक पहुंच देने के बजाय, मैंने एक संग्रहीत प्रक्रिया का उपयोग किया जो कि केवल वही करता है जो आवश्यक है, और केवल सीमित जानकारी देता है। वेब एप्लिकेशन को तब केवल इस संग्रहीत कार्यविधि तक पहुंच दी जा सकती है, बिना किसी टेबल आदि के उपयोग के।
यहाँ एक ही बात: एक साधारण कनेक्शन स्ट्रिंग और अद्यतन और आपकी समस्या है। यह समस्या एक ORM के साथ भी हल की जा सकती है :
बस दूसरे DB के सामने एक webservice का उपयोग करें और एक ही compartementalization / अलगाव हासिल किया जाता है।
इसलिए यहां देखने के लिए कुछ नहीं है।
कुछ अन्य बिंदुओं को देखते हुए:
आपके पास काम की जटिल इकाइयाँ हैं, जिनमें शायद कई तालिकाओं को शामिल किया गया है, जिन्हें आसानी से EF की सुविधाओं का उपयोग करके लेनदेन में नहीं लपेटा जा सकता है।
लेकिन SQLऐसा कर सकते हैं। यहां कोई जादू शामिल नहीं है।
आपका डेटाबेस EF के साथ अच्छा नहीं खेलता है
फिर: उपयुक्त होने पर ईएफ का उपयोग करें ।
आपको उन डेटा के साथ काम करना होगा जो लिंक किए गए सर्वर के साथ सर्वर की सीमाओं को पार करते हैं
मैं नहीं देखता, कैसे संग्रहीत कार्यविधियाँ मदद करती हैं। इसलिए मैं संग्रहीत प्रक्रियाओं का लाभ नहीं देख सकता हूं ; लेकिन शायद किसी ने उस पर कुछ प्रकाश डाला।
आपके पास बहुत जटिल डेटा पुनर्प्राप्ति परिदृश्य हैं जहां पर्याप्त प्रदर्शन सुनिश्चित करने के लिए "नंगे धातु" SQL की आवश्यकता है
दोबारा: " ईएफ की सीमाएं "।
आपके आवेदन में एक मेज पर पूर्ण सीआरयूडी की अनुमति नहीं है लेकिन आपके आवेदन को एक सुरक्षा संदर्भ के तहत चलाने की अनुमति दी जा सकती है जो आपके सर्वर पर भरोसा करता है
ठीक है। मैं शायद साथ जाता हूं ।
अब तक केवल एक आधा बिंदु संग्रहीत प्रक्रियाओं के पक्ष में बनाया गया था।
शायद प्रदर्शन विचार हैं, जो संग्रहीत प्रक्रियाओं के पक्ष में बोलते हैं।
1) स्टोरेज क्वेरी में एक साधारण का लाभ है संग्रहित प्रक्रिया को कॉल का लाभ होता है जो जटिलता को घेरता है। चूंकि क्वेरी प्लानर क्वेरी को जानता है, इसलिए इसे अनुकूलित करना "आसान" है। लेकिन बचत वर्तमान परिष्कृत क्वेरी प्लानर _minimal के साथ है।
उसके शीर्ष पर, भले ही तदर्थ प्रश्नों का उपयोग करने में थोड़ी लागत हो , यदि आपका डेटा अच्छी तरह से संरचित और सावधानी से अनुक्रमित है, तो डेटाबेस केवल अड़चन है आपके आवेदन है। यहां तक कि अगर एक छोटा डेल्टा है, तो भी अन्य कारकों पर विचार करना उपेक्षित है।
2) फिर भी यह भंडारण के लिए तर्क दिया गया था जटिल डीबी में प्रश्नों को । विचार करने के लिए दो चीजें हैं:
क) जटिल प्रश्न डीबी बुनियादी ढांचे का बड़े पैमाने पर उपयोग करते हैं, जो हर दूसरे प्रश्न के लिए कई बार बढ़ जाता है। आप समानांतर में कई महंगे प्रश्नों को नहीं चला सकते हैं । यह न तो बोलती समर्थक है और न ही विपरीत संग्रहित प्रक्रियाओं, लेकिन के खिलाफ जटिल प्रश्नों के ।
b) यदि क्वेरी में समय लगता है, तो किसी संग्रहीत प्रक्रिया की छोटी गति की जीत से परेशान क्यों हैं।
tl; डॉ
कुछ भी सीधे खिलाफ नहीं बोलता संग्रहीत प्रक्रियाओं के । तो संग्रहीत प्रक्रियाओं का उपयोग करना ठीक है - अगर यह आपको खुश करता है।
लेकिन दूसरी ओर: मैं एक उचित उपयोग के मामले की कल्पना नहीं कर सकता, जो असमान रूप से बोलता है ।
मुझे संग्रहीत प्रक्रियाओं का उपयोग कब करना चाहिए?
उचित उत्तर है: जब भी आप चाहें । लेकिन अन्य विकल्प भी हैं।