संग्रहित प्रक्रियाएं - दिनों का अंत

Question

मैं हंसेलमिंट्स पॉडकास्ट को सुन रहा हूं; "स्टैक ओवरफ्लो एएसपी.नेट एमवीसी - जेफ एटवुड और उनकी तकनीकी टीम का उपयोग करता है"। पॉडकास्ट के दौरान वे एसक्यूएल सर्वर के बारे में बात कर रहे हैं और 'संग्रहीत प्रक्रिया के दिन खत्म हो गए हैं' के आधार पर कुछ कहें।

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

Answer 1

आधुनिक सिस्टम पर, पैरामीटरयुक्त प्रश्न सर्वर पर संकलित और कैश किए जाते हैं, इसलिए वे संग्रहीत प्रक्रिया के जितना तेज़ होते हैं। उनके पास समान सुरक्षा सुविधाएं भी हैं।

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

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

Answer 2

एसपी शायद संभवतः जाने के लिए रास्ता हैं यदि आप केवल गति के बारे में चिंतित हैं। लेकिन यदि आप स्केलेबिलिटी या रखरखाव की परवाह करते हैं, तो एसपी शायद सबसे अच्छा नहीं हो सकता है। हमारा आर्किटेक्चर एसपी पर बनाया गया है और 10 साल के कोड के बाद, इसे बनाए रखना बहुत मुश्किल है और बहुत छोटी है। एक अच्छा ओआरएम मैपर बेहतर विकल्प हो सकता है।

Answer 3

मैं कहूंगा कि एसपीएस बनाए रखने योग्य नहीं हैं और वे स्केल नहीं करते हैं। किसी भी डेवलपर से पूछें जिसे एसपी भारी प्रणाली में कार्यक्षमता जोड़नी है। एक अलग परत में आधा तर्क क्यों है? प्रतिस्थापित करने के लिए कुछ भी नहीं है, बस 'em का उपयोग न करें।

Googled this great post.

Answer 4

ORM और LINQ एसक्यूएल को StoredProcs की जगह के लिए मौजूदा रुझान होने लगते हैं।

मैंने व्यक्तिगत रूप से ओआरएम का उपयोग किया है और इसे बनाए रखने और समर्थन के लिए बहुत आसान लगता है।

संग्रहीत प्रोसेस का उपयोग करने के लिए कहा गया कुछ कारण जहां कभी भी वैध कारणों से शुरू नहीं होता है।

जब आप एकाधिक अनुप्रयोगों की सेवा करते हैं तो आप संग्रहित प्रक्रियाओं के बारे में एक अच्छा बिंदु बनाते हैं; वे अनिवार्य रूप से डीएएल बन जाते हैं, आमतौर पर वहां कुछ व्यावसायिक तर्क के साथ।

Answer 5

शायद मैं बहुत पुराना स्कूल, या बहुत आलसी हूं, या दोनों, लेकिन मुझे असहमत होना है। समय-समय पर संग्रहीत प्रक्रियाओं ने 'दिन बचा लिया' क्योंकि जब मामूली बैक-एंड चेंज या बग दिखाई देता है तो हमें डेस्कटॉप एप्लिकेशन को कई दर्जन डेस्कटॉप और वेब सर्वर पर अपडेट करने के बजाय संग्रहीत प्रक्रिया को ठीक करना होगा। इसके अतिरिक्त, उपयोगकर्ता बाधित नहीं हैं। यह प्रयास और उपयोगकर्ता परेशानी का एक बड़ा सौदा बचाता है।

इसके अलावा, कुछ डीबी संचालन नेटवर्क पर आगे और आगे जाने के बजाए सर्वर पर अधिक कुशल होने जा रहे हैं। जब एक संग्रहीत प्रक्रिया किसी अन्य को कॉल करती है जो (अन्य के साथ या बिना कर्सर)

संपादित करें: एसओए आर्किटेक्चर में अद्यतन-द-क्लाइंट-ऐप्स समस्या कम हो जाती है (धन्यवाद maud-dib), लेकिन प्रत्येक को कॉल करने वाली संग्रहीत प्रक्रियाएं अन्य एसओए परत के लिए कई नेटवर्क राउंड-ट्रिप की तुलना में अभी भी अधिक कुशल है।और एसओए परत को अद्यतन करना हमेशा तुच्छ नहीं होता है।

Answer 6

यह भी आपकी संग्रहीत प्रक्रियाओं के आधार पर निर्भर करता है।

उदाहरण के लिए अगर यह केवल

select a from b where x = y 

तो एक संग्रहीत प्रक्रिया शायद overkill है। लेकिन मैं व्यक्तिगत रूप से डेटाबेस के भीतर कई परिणाम सेट और पेज परिणाम लौटने के लिए संग्रहीत प्रोसेस का उपयोग करता हूं।

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

संग्रहीत प्रक्रियाओं के साथ एक अच्छी परियोजना हमेशा बिना किसी कमजोर परियोजना से बेहतर होगी और इसके विपरीत।

Answer 7

बस मेरी छोटी सलाह यहां फेंक दें। एसक्यूएल 2005 से पहले (शायद इससे भी आगे), एसपी तेजी से थे। हालांकि, SQL सर्वर 2005 और ऊपर वास्तव में अनुकूलित हैं और वे आपके प्रश्नों को कैश करते हैं जैसे आप जाते हैं। असल में, हमारे पास एक नया SQL सर्वर एक ट्रांसफर किया गया था। एप्लिकेशन हर किसी के लिए धीमा चलकर शुरू हुआ। सब कुछ "एक सेकंड के 3/4" या 1 सेकंड चलाने के लिए ले रहा था। फिर एसक्यूएल ने सबसे अधिक इस्तेमाल की गई क्वेरी को संकलित करना शुरू कर दिया और सबकुछ धीरे-धीरे तेज से तेज हो गया।

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

Answer 8

यह प्रश्न one posted earlier today में भी खून बह रहा है।

Answer 9

जब आप एसपी को डेटाबेस के साथ तर्क के साथ जोड़ते हैं, तो आप प्रभावी रूप से डीबी को एप्लिकेशन सर्वर के समान रूप से परिवर्तित करते हैं।

वापस जब यह हथौड़ा सबसे आसान था, तो यह बहुत समझ में आया। लेकिन अब आवेदन सर्वर की सर्वव्यापी उपलब्धता के साथ, यह केंद्रीकृत तर्क और व्यावसायिक नियमों जैसी चीजों के लिए उन्हें लाभ उठाने के लिए और अधिक समझ में आता है और केवल दृढ़ता के लिए डीबी पर भरोसा करता है।

Answer 10

इस साइट के कम प्रदर्शन से निर्णय लेने के बाद, मैं प्रमुख बाधा डेटाबेस को दांव लगाने जा रहा हूं।

मुझे किसी भी तरह से आश्वस्त नहीं है कि वे LINQ 2 SQL ORM का उपयोग कर रहे हैं जो एक स्पोक से थोड़ा तेज है।

Answer 11

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

Answer 12

मैं इस तर्क को सुनता रहता हूं कि यदि आपके पास डेटाबेस से कनेक्ट होने वाले एकाधिक एप्लिकेशन हैं या यह बग फिक्सिंग को आसान बनाता है तो एसपी अच्छे हैं।

यह है कि एक सेवा लेयर के लिए क्या है!

बिजनेस लॉजिक सर्विस लेयर में जाता है, एप्लिकेशन लॉजिक एप्लिकेशन/वेब साइट पर जाता है।

एक ओआरएम उपकरण के माध्यम से डीबी से बात करने वाले अच्छी तरह से लिखित कोड को बनाए रखने के लिए सैकड़ों एसपी (विशेष रूप से वहां उत्पन्न होने पर) को डीबग और बनाए रखना बहुत मुश्किल है।

Answer 13

रखरखाव शायद एसपी बेहतर हैं। यदि एसपी के हुंडर्स को बनाए रखना मुश्किल है, तो उन्हें व्यापार स्तर के घटकों में बनाए रखना भी कठिन होता है।

प्रदर्शन प्रश्नों का कैशिंग एसपी के प्रदर्शन के करीब उत्पादन कर सकता है। लेकिन वे मंच की किस्मों में डेटाबेस की किस्मों में एसपी के प्रदर्शन से मेल नहीं खा सकते हैं। नेटवर्क विलंबता चिंता का एक और क्षेत्र है, हालांकि आजकल अंतर कम हो रहा है।

डीबग शायद व्यापार स्तरीय + डीबी टियर को डीबग करने से एसपी के साथ काफी आसान है।

एसपी का उपयोग करके और भी अधिक अंक हो सकते हैं।

लेकिन प्रोग्रामिंग के आधुनिक रुझान को देखते हुए इसके बजाय "बुद्धिमान" के साथ "पुराने" सपा आधारित दृष्टिकोण चिपके से व्यावसायिक कारणों से बहुत सारे के लिए 'एन' स्तरीय संरचना के साथ जाने के लिए।

अच्छी प्रणाली में दोनों का मिश्रण होना चाहिए। शायद 80-20 सिद्धांत के बाद, 20 एसपी होने के नाते।

Answer 14

क्या यह हो सकता है कि जेफ एटवुड जानता है संग्रहीत प्रक्रिया हमेशा के लिए रहेगी और केवल विचार और बहस को प्रोत्साहित करने की कोशिश कर रही थी? मुझे यह सोचना अच्छा लगता है कि वह वास्तव में क्या करना चाहता है, "संग्रहीत प्रक्रियाओं को हानिकारक माना जाता है" नामक एक प्रेरक निबंध लिखना है :)

Answer 15

कुछ अच्छे बिंदु दोनों पक्षों (जैसे थे) पर बनाते हैं लेकिन किसी ने भी बहुत कुछ नहीं किया है सुरक्षा निहितार्थ का। एसपी में सभी डीबी इंटरैक्शन को लपेटने का मतलब है कि आप डीबी को लॉक कर सकते हैं ताकि डेटा के साथ किसी भी बातचीत को कड़ाई से नियंत्रित किया जा सके।

आप Encapsulation के बारे में सोच रहे हैं, तो आप तरीकों और गुण है कि बाहर की दुनिया से वस्तुओं की कार्यक्षमता का पर्दाफाश के रूप में एक वस्तु के रूप DB और एस.पी. संबंध कर सकते हैं।

कुछ बड़े विकास के वातावरण, यूआई और व्यापार परत डेवलपर्स में डीबी के पास अनुमति नहीं है। वे अपनी आवश्यकताओं को निर्दिष्ट करते हैं और अलग टीम एसपी के माध्यम से प्रदान करता है और इंटरफेस करता है।

वहाँ एस.पी. और केवल उन्हें प्रयोग करने के कुछ अच्छे कारणों का उपयोग नहीं के लिए कुछ अच्छे कारण हैं - अपने आवेदन और अपने वातावरण पर निर्भर करता है। लेकिन बाकी आश्वासन दिया कि एसपी जल्द ही कहीं भी नहीं जा रहे हैं।

Answer 16

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

मैं मानता हूं कि कुछ सरल सामान जैसे कि SELECT, INSERT, UPDATE, DELETE को ओआरएम, लिंक द्वारा देखभाल की जा सकती है।

इसलिए, यह कहना है कि संग्रहित प्रक्रियाओं के दिन ख़त्म हो रहे हैं बेवकूफ है।
डीबी प्लेटफॉर्म परिवर्तनों (एसक्यूएल से माइस्क्ल, ओरेकल) के बारे में कितने लोगों को वास्तव में चिंता करने की ज़रूरत है?

Answer 17

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

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

यदि आपका डेटा स्टोर xml है, या विश्लेषणात्मक डेटाबेस है तो वे इतने आसान नहीं हैं।

Answer 18

बह!

ओआरएम, एसपी, व्यू, मैजिक वंड्स, या जो भी हो।

प्रत्येक "टूल" में आपकी बेल्ट में जगह है, जो टूल आपके पास बुद्धिमानी से उपयोग करें।

एकमात्र चीज जिसने "बदले" (वास्तव में सुधार किया है) यह है कि कुछ ओआरएम में पहले से ही बेक किया गया अच्छा कैशिंग उपकरण है और MySQL और Sql 2005+ गतिशील या विज्ञापन संबंधी क्वेरी/निष्पादन योजना कैशिंग को संभाल सकता है।

आपके डीबी सर्वर पर गतिशील एसक्यूएल के सभी प्रकारों को फेंकने से संभावित प्रदर्शन हानि कुछ हद तक कम हो गई है। अब संग्रहित प्रक्रियाओं के बिना जाना आसान है। संग्रहीत प्रक्रिया कहीं भी नहीं जा रही हैं।

Answer 19

संग्रहीत प्रक्रियाओं/दृश्य/कार्य अभी भी डेटाबेस के लिए एक अच्छा "इंटरफ़ेस" हैं यदि आप एक ही डेटाबेस साझा करने वाले एकाधिक एंटरप्राइज़ एप्लिकेशन चला रहे हैं।

ऐप # 1 - आपको एक नया रिश्ते/फ़ील्ड जोड़ने की ज़रूरत है, या एक शून्य कॉलम को शून्य नल में बदलना होगा।

अनुप्रयोग # 2-10 - या इस डेटाबेस वस्तु

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

यह एकमात्र कमी है जो मुझे टेबल तक सीधे पहुंच प्राप्त हुई है।

एकल डेटाबेस का उपयोग कर एक ही एप्लिकेशन के लिए, यह वास्तव में कोई समस्या नहीं है। हालांकि आपको अभी भी डेटाबेस के अलावा निर्भरताओं के लिए एप्लिकेशन कोड देखना होगा।

Answer 20

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