कोड को और अधिक रखरखाव करने के इरादे से संग्रहित प्रक्रियाओं में कोड डालने के लिए और तर्क के खिलाफ क्या तर्क है (यानी कोड को दोबारा कोड किए बिना व्यवसाय नियमों में परिवर्तन करना आसान है)?संग्रहित प्रक्रियाओं को बनाए रखने के लिए आसान हैं?
अन्य सभी समान हैं जो संग्रहीत प्रक्रिया को रखरखाव के लिए बेहतर/बदतर बनाते हैं?
संग्रहीत प्रक्रियाएं कई कारणों से खराब अभ्यास हैं।
सबसे महत्वपूर्ण लोगों में से एक की चिंताओं की जुदाई है। संग्रहीत प्रक्रियाओं के साथ, आपके पास सेवा परत में, जहां यह संबंधित है, डेटा परत में व्यावसायिक तर्क है। इसका एक परिणाम यह है कि अब आपके पास एक भाषा और एक भाषा है जिसमें आपके व्यवसाय तर्क को लागू करना है। जैसे-जैसे नई तकनीकें आती हैं, आपके पास कोई अच्छा माइग्रेशन पथ नहीं है।
संग्रहित प्रक्रियाओं से बचने के लिए एक और ठोस कारण यह है कि संग्रहित प्रक्रियाओं आप और डीबी विक्रेता के बीच एक मजबूत रिश्ता बनाने के लिए है। किसी भी डीबी विक्रेता को कभी भी बदलना बहुत कठिन होगा, जबकि सेवा परत में आपका व्यावसायिक तर्क होने से आप डीबी को आसानी से स्वैप कर सकते हैं। इसलिए, संग्रहीत प्रक्रियाएं डीबी विक्रेता को बहुत लाभ प्रदान करती हैं, और आपके लिए बहुत कुछ नहीं।
अगला, स्केलेबिलिटी। मध्यम स्तर पर सेवाओं को बनाने के लिए यह बहुत सरल है, और उन्हें क्लस्टर में वितरित करें। आप एक संग्रहीत प्रक्रिया के साथ ऐसा करने के लिए कैसे जा रहे हैं? मुझे लगता है कि एक संग्रहीत प्रक्रिया को क्लस्टर करना मुश्किल होगा, कहें, यहां तक कि आठ मशीनें भी।
इसके बाद, अन्य प्रणालियों के साथ एकीकरण।यदि आपका सिस्टम आपके डेटाबेस से डेटा खींच रहा है, संग्रहीत प्रक्रियाओं पर निर्भर है, और अन्य सिस्टम से अन्य डेटा, तो तर्क लगभग निश्चित रूप से एक सेवा परत में होना होगा। यदि आपके कुछ व्यवसाय तर्क सेवा परत में हैं, और कुछ व्यवसाय परत में हैं, तो आपके पास रखरखाव की परेशानी है।
संग्रहीत प्रक्रियाओं में व्यावसायिक तर्क नहीं होता है, वे तालिकाओं के कार्यान्वयन विवरण छुपाते हुए एक दृढ़ता इंटरफ़ेस प्रस्तुत करते हैं। आम तौर पर कार्यान्वयन विवरणों का समावेशन अच्छा अभ्यास माना जाता है। –
मुझे यकीन नहीं है कि मैं कहूंगा कि वे एक बुरी आदत हैं ... मैं निश्चित रूप से आपके द्वारा उल्लिखित कुछ कारणों से बचने की कोशिश करता हूं। – mattruma
@ ग्रेग - मैंने संग्रहीत प्रक्रियाओं को देखा है जिनमें बस शामिल है। तर्क। तो, एक कंबल कथन बनाने के लिए कि वे सच नहीं है। अगर वे करते हैं, तो यह बुरा है। जब वे नहीं करते हैं, तो यह एक बड़ा सौदा है। –
मैं संग्रहीत प्रक्रियाओं के खिलाफ बहस नहीं कर रहा हूं, लेकिन मैं सुझाव दूंगा कि उन्हें बनाए रखना कठिन होगा क्योंकि उन्हें एप्लिकेशन के अपडेट से स्वतंत्र रूप से अपडेट किया जाना चाहिए (उन्हें एसक्यूएल सर्वर में संग्रहीत किया जाना चाहिए)।
क्या यह बड़ा, अधिक मोनोलिथिक अनुप्रयोगों के लिए एक तर्क है? अन्य लोग कहते हैं, "उन्हें बनाए रखना आसान है क्योंकि उन्हें आवेदन के अपडेट से स्वतंत्र रूप से अपडेट किया जा सकता है", दोनों के बीच युग्मन को कम करना "(जैसा कि किसी अन्य वितरित प्रसंस्करण संदर्भ में) है। आपकी प्राथमिकताओं पर निर्भर करता है। – dkretz
यह भी एक लाभ है - साझा पुस्तकालयों की तरह। –
मुझे आपके द्वारा प्रस्तावित कारण एक अच्छा कारण नहीं है। चूंकि वे एप्लिकेशन और डेटा परत के बीच decoupling में मदद करते हैं, वे एक अच्छा अभ्यास होगा और कोड-पुनर्लेखन को कम करेगा। – Tarik
यह शायद आपके सिस्टम पर निर्भर करता है। हमारे लिए, संग्रहीत प्रक्रिया लगभग पूरी तरह से उपयोग की जाती है। हमारे पास सिर्फ एक वेबसाइट है, इसलिए एक संग्रहित प्रो में SQL कथन होने से हमारे डीबीए के लिए प्रश्नों को ट्यून करना और मुद्दों को उत्पन्न करने के प्रदर्शन को फिर से बनाना बहुत आसान हो जाता है। प्रोजेक्ट में
मैं काम कर रहा हूं, अधिकांश रखरखाव केवल एसक्यूएल प्रक्रियाओं को बदलकर पूरा किया जा सकता है। इसलिए हाँ स्टोर प्रक्रियाएं मेरे मामले में अधिक रखरखाव योग्य हैं, उनके कोड से एसक्यूएल स्टेटमेंट निष्पादित करने के बजाय उनके पास बेहतर प्रदर्शन भी है।
यदि आपका बेस सॉफ़्टवेयर कई अलग-अलग ग्राहक साइटों पर तैनात किया गया है, तो प्रत्येक ग्राहक के लिए आवश्यक अधिकांश अनुकूलन डेटाबेस (दृश्य और संग्रहीत प्रक्रियाओं) के माध्यम से पूरा किया जा सकता है। आप एसपी के बारे में लगभग एक इंटरफेस के रूप में सोच सकते हैं, अंदर के अंदर होने वाली चिंता के बिना मानक डेटा को पीछे और आगे पास कर सकते हैं।
यह निश्चित रूप से, प्रत्येक इंस्टॉलेशन के लिए कस्टम। डीएल डेटा परत जैसे अन्य तरीकों से भी संभाला जा सकता है।
कुछ मामलों में, हालांकि। डीएल के बजाय एसपी में अनुकूलन तेजी से अनुकूलन की अनुमति देता है और प्रोग्रामर को कोडिंग पर काम करने के लिए छोड़कर डीबीए या डेटा विशेषज्ञ को लेने की अनुमति देता है।
याद रखें कि एसपी में कोड संकलित कोड की तुलना में कई लोगों (ग्राहक, इस मामले में) के लिए उपलब्ध है। यह आपकी स्थिति के आधार पर अच्छा या बुरा हो सकता है।
कुछ उद्यमों में, सॉफ्टवेयर को पुन: स्थापित करने की तुलना में संग्रहीत प्रक्रिया को बदलने के लिए राजनीतिक रूप से आसान है (जो अधिक कड़े नियमों के बारे में अधिक निर्भर करता है, डेवलपर्स & प्रोजेक्ट मैनेजर्स, डीबीए, या आईटी/सहायता केंद्र)।
समान, फ्लाई पर बदलने के लिए यह बुरा अभ्यास है, क्या आपको याद है?
गंभीरता से, संग्रहीत प्रक्रिया में कोड बनाने से आप सुनिश्चित कर सकते हैं कि आपकी एसक्यूएल इंटरैक्शन तेजी से है।
लेकिन आपके परिवर्तन स्रोत-नियंत्रण से बहुत दूर हैं। (स्रोत नियंत्रण के लिए, आपको निर्यात करने की आवश्यकता है, जैसा कि मुझे पता है)
मेरी संग्रहीत प्रक्रियाओं को पाठ फ़ाइलों के रूप में सहेजा जाता है उपवर्तन नियंत्रण के तहत एक फ़ोल्डर में। वे संपादित, चेक-इन, और फिर परीक्षण डेटाबेस में लोड हो जाते हैं, और परीक्षण किए जाते हैं। आपको स्रोत नियंत्रण का उपयोग करने के लिए कुछ भी निर्यात करने की आवश्यकता नहीं है। कभी भी एंटरप्राइज़ मैनेजर का उपयोग नहीं करना चाहिए या आपके परिवर्तनों को IMO बनाने के समान नहीं होना चाहिए – MikeW
@MikeW, दिलचस्प विचार। – Avram
मुझे भी - मैं किसी भी एसपी को (उत्पादन या यहां तक कि एक परीक्षण) डेटाबेस के पास नहीं जाने दूंगा जो आपको नहीं था एक वीसीएस प्रस्तुत करना; सब कुछ एक वीसीएस के तहत होना चाहिए। –
आम तौर पर, यह तर्क इसलिए किया जाता है क्योंकि आप संग्रहीत प्रोसेस, परीक्षण इत्यादि के माध्यम से संग्रहीत प्रोसेस में विज्ञापन-परिवर्तन परिवर्तन कर रहे हैं जो संकलित है कोड के माध्यम से जाना होगा।
मेरे पास तत्काल घुटने झटके की प्रतिक्रिया नहीं है (यहां अधिकांश लोगों के विपरीत), लेकिन मैं कहूंगा कि डीएलएल को संकलित और तैनात करना वास्तव में उस प्रकार के चरवाहे पर्यावरण में इतना कठिन नहीं है। या, आप सीएस-स्क्रिप्ट जैसे कुछ का उपयोग कर सकते हैं, जो आपको मांग पर संकलित कच्चे .cs फ़ाइलों को रखने की अनुमति देता है।
मुझे हमेशा संस्करण में मुश्किल लगती है और संग्रहित प्रोसेस का परीक्षण होता है, जबकि अधिकांश कोड आसानी से किया जाता है। इसके अलावा, अधिकांश आरडीबीएमएस प्रक्रियात्मक भाषाएं बहुत प्राचीन हैं - इसलिए आप अभिव्यक्ति या अवशोषण नहीं करते हैं जो एक समकालीन भाषा आपको देता है।
बेशक, संस्करण नियंत्रण एक अच्छी बात है - और, सबसे अधिक स्थानों के लिए है, तो devs और उत्पादन के बीच कुछ प्रक्रिया की जाँच करता है। ;)
स्रोत नियंत्रण के माध्यम से नहीं जाने के लिए प्रतिक्रिया घुटने झटका नहीं है। –
प्रतिक्रिया की गंभीरता, प्रतिक्रिया स्वयं ही नहीं, यह निर्धारित करती है कि यह घुटने झटका है या नहीं। इस मामले पर बहुत से लोगों की तत्काल और संकीर्ण राय है और किसी भी वैकल्पिक विचारों का मनोरंजन करने से इंकार कर दिया है। वह घुटने झटका है। – Chris
मुझे लगता है कि यह प्रभावित करता है एक कारक ग्राहकों की संख्या है, क्योंकि यह यह संभव क्षुधा पुनर्वितरित बिना स्कीमा परिवर्तन करने के लिए बनाता है के फायदे। जैसे एक डीबीए के रूप में मुझे एसक्यूएल को ट्यून करने, बग को हल करने, आदि को एक्स कंटेंट करने के बजाय एक्स स्टोर्स को बदलने के बजाए एक संग्रहित प्रक्रिया में जाने के लिए बहुत आसान लगता है, जब एक्स बड़ी संख्या में होता है और 'विज़िट' होता है, तो ऐप का एक नया संस्करण तैनात करना है एकाधिक वर्कस्टेशन के लिए।
हो गया ठीक से यह भी मतलब है कि स्कीमा कि आवेदन का उपयोग करता है thedata भंडारण स्कीमा से अलग हो सकता है। जैसे मैं डेटा स्कीमा को अत्यधिक सामान्य बनाना चाहता हूं और एप्लिकेशन का उपयोग करने वाले दृश्यों और संग्रहित प्रोसेस का एक सेट प्रदान करना चाहता हूं। ऐप्स स्कीमा ऐप कोड में परिवर्तन और डेटा स्कीमा से स्वतंत्र समय के साथ बदलता है। इस बहु-आवेदन प्रणाली के साथ एक वास्तविक लाभ यह है (उदाहरण के लिए एक पढ़ने-लिखने की एप्लिकेशन और एक ही डेटा का उपयोग कर एक वेब साइट अनुप्रयोग।)
का नुकसान अक्सर उपकरणों का एक अलग सेट है और संग्रहीत प्रोसेस लिखने के लिए उपयोग की जाने वाली एक अलग भाषा। प्रशिक्षण, कौशल विकास इत्यादि की आवश्यकता के लिए यह बाधा हो सकती है।
"प्रायः संग्रहीत प्रोसेस लिखने के लिए औजारों का एक अलग सेट और एक अलग भाषा होती है।" किसी को डेटाबेस में हेरफेर में कुशल बनने की आवश्यकता होगी, चाहे उद्देश्य के लिए नए और अलग डीबीएमएस उपकरण में या भाषा में नए और विभिन्न टूल्स। – dkretz
मुझे लगता है कि मेरे अनुभव में मुख्य नुकसान यह है कि मैंने जिन डेवलपर्स के साथ काम किया है, वे वास्तव में एसक्यूएल के साथ सहज थे (इसे पहले स्थान पर लिखना , इसे डीबग करना) तो आपको यह सुनिश्चित करना होगा कि आपके पास बहुत सी एसक्यूएल बनाए रखने में सक्षम होने के लिए आपकी टीम में सही कौशल सेट होगा।
एक बड़ा लाभ आप कई प्लेटफार्मों (जैसे कि दोनों खिड़कियों और वेब एप्लिकेशन) है या आप बंदरगाह एक नई तकनीक के लिए एक पुराने अनुप्रयोग, आप डेटाबेस प्रक्रियाओं का पुन: उपयोग करने में सक्षम हो सकता है, अगर हो सकता है।
जिस एप्लिकेशन के साथ मैं काम कर रहा हूं, उसके पास संग्रहीत प्रक्रियाओं में बहुत सारी व्यावसायिक कार्यक्षमता है, और शायद हम जो आधे बग ठीक करते हैं, वे SQL कोड में हैं, और अगर किसी संग्रहीत प्रक्रिया को प्रतिस्थापित करके महत्वपूर्ण रूप से ठीक किया जा सकता है, एप्लिकेशन कोड में बग जो अगली रिलीज के लिए प्रतीक्षा करनी चाहिए। (हालांकि फ्लिप पक्ष यह है कि अगर हमने इतना एसक्यूएल कोड नहीं लिखा है, तो हम पहले कम में कम बग्स ले सकते हैं!)
स्पोक में कोई बदलाव क्यों नहीं करता है। अगली रिलीज के लिए इंतजार करने की जरूरत है? –
अच्छा मुझे लगता है कि यह चाहिए। मुझे लगता है कि मेरा मुद्दा यह था कि हमारे मामले में हम शायद ही कभी शाखा के लिए एक रास्ता बनाते हैं और आवेदन करते हैं, लेकिन हम प्रायः एक संग्रहीत प्रक्रिया को ठीक करते हैं क्योंकि वे आवेदन कोड की तुलना में ठीक करने और पुन: नियोजित (हमारे मामले में) अपेक्षाकृत आसान होते हैं। – MikeW
मेरा अनुभव यह है कि स्रोत नियंत्रण के लिए डाटाबेस को बनाए रखने के लिए स्रोत नियंत्रण को शायद ही कभी परिश्रम के रूप में उपयोग किया जाता है। निश्चित रूप से, यह शायद हमेशा मामला नहीं है, लेकिन 15 वर्षों में मैंने इसे कभी नहीं देखा है। इसका मतलब यह है कि आप लोगों को देव में परिवर्तन करने की अधिक संभावना है, और स्वर्ग जीवित मना कर देता है, डेटाबेस संग्रहीत प्रोसेस को रखरखाव को कम करने के लिए कोई वास्तविक विचार नहीं है क्योंकि यह बहुत आसान है।
अनुशासन की कमी एक तकनीक को नजरअंदाज करने का कारण नहीं है; यह डेटाबेस की गलती नहीं है! हम अपने किसी भी अन्य कोड के लिए हमारे डेटाबेस के लिए सटीक उसी स्रोत नियंत्रण/कोड समीक्षा/तैनाती प्रक्रियाओं का पालन करते हैं। –
तो आपका एक तो। – Craig
शायद मेरा जवाब स्पष्ट नहीं था। संग्रहीत प्रोसेस का उपयोग करने का कोई तकनीकी कारण कम रखरखाव नहीं है और स्रोत नियंत्रण का उपयोग नहीं किया जा सकता है। लेकिन हकीकत में यह शायद ही कभी होता है। – Craig
मैं संग्रहित प्रक्रियाओं का उपयोग नहीं करना पसंद करता क्योंकि मुझे अपेक्षाकृत डेटाबेस अज्ञेयवादी रहना पसंद है। यदि एक बेहतर संबंधपरक डेटाबेस साथ आता है, तो मैं इसे माइग्रेट करने का विकल्प चाहता हूं। संग्रहीत प्रक्रियाएं आपको लॉक कर देगी। उन्होंने कहा, मैं कभी-कभी उनका उपयोग करता हूं, वे बहुत शक्तिशाली हो सकते हैं। विकल्प के
सोचें ...
फिर अपनी आवश्यकताओं और पर्यावरण पर विचार ...
अपने डेवलपर्स अपने डेटाबेस प्रबंधन उपकरण से परिचित हैं या आप अधिक डेटाबेस प्रोग्रामर और प्रशासकों तो बाड़ के डाटाबेस की ओर से निपटने के लिए क्या है?
क्या आपको डीबी स्कीमा में लगातार परिवर्तन करने की आवश्यकता है?
सुरक्षा के बारे में कैसे? क्या आपको किसी डेटाबेस उपयोगकर्ता स्तर पर सुरक्षा की आवश्यकता है? कोड में सुरक्षा या डीबी में सुरक्षा का प्रबंधन करना आसान होगा?
क्या आपके डेवलपर्स ओआरएम के साथ अधिक उत्पादक होंगे, खुद के लिए एक डीएएल नहीं लिखना चाहते हैं या क्या ऐसी जटिलता है जिसे आप अपने डीएएल को कस्टम फैशन में जोड़ना चाहते हैं जो एक ओआरएम प्रदान नहीं कर सका?
आदि ...
लोग या नहीं, procs सिस्टम और वातावरण किस तरह का है कि वे उस में काम किया है के आधार पर रेख करना आसान कर रहे हैं पर अलग राय है करने के लिए जा रहे हैं शायद अब तक अलग हैं अपने आप से आपको शायद यह सोचने के बजाय क्या करना चाहिए कि क्या उन्हें बनाए रखना आसान है, यह पता लगाना है कि वे आपकी ज़रूरतों को पूरा करते हैं या नहीं। यह वास्तव में एक अच्छा सवाल है, लेकिन हो सकता है कि आप अपनी पोस्ट संपादित करें और अपने env के बारे में कुछ और बताएं। और आपको थोड़ी अधिक लक्षित सलाह मिल सकती है।
एक बहुत अच्छा और संतुलित उत्तर ... –
मैंने व्यवसाय दुनिया में 10+ वर्षों के लिए सलाहकार के रूप में सीआरयूडी प्रोग्रामिंग किया है। मैं आपको बता सकता हूं कि मैंने sprocs & विचारों में जितना अधिक व्यवसाय तर्क डाल दिया है (और समझ में आता है)। हर बार जब हवाएं उड़ती हैं और डेटाबेस में तर्क होने की आवश्यकता होती है तो यह बदलना आसान हो जाता है और (सभ्य टिप्पणियों के साथ) यह स्वयं दस्तावेज है। प्लस स्पॉक्स अच्छी सुरक्षा के लिए और आसान कोड पुन: उपयोग के लिए बनाते हैं।
एफडब्ल्यूआईडब्ल्यू मैं अपने सभी sprocs पर स्रोत नियंत्रण और सख्त परीक्षण का उपयोग करता हूं। अन्यथा करना आलसी है।
क्या होगा यदि व्यापार तर्क बाहरी सेवा (वेब सेवा या फ़ाइल सिस्टम कॉन्फ़िगरेशन) पर आधारित है? अगर डिस्कनेक्ट किए गए वातावरण में एप्लिकेशन को काम करने की ज़रूरत है तो आप क्या करते हैं? –
यही कारण है कि पैरामीटर और बिज़टक का आविष्कार 8 डी –
था, मुझे नहीं लगता कि यह एक स्पोक से वेब सेवा को कॉल करने की समस्या को कैसे हल कर सकता है। जो मैं जिक्र कर रहा था। –
संग्रहित प्रक्रियाओं कारण के एक नंबर के लिए एक अच्छा विचार कर रहे हैं:
व्यावसायिक डेटा के करीब तर्क डाल करके, आप डेटा के लिए ग्राहक इंटरफ़ेस के किसी भी संख्या के लिए सक्षम हैं। आप शुरुआत में वेब साइट के लिए फ्रंट एंड डिज़ाइन कर सकते हैं लेकिन अब वे रिपोर्ट चाहते हैं। कोई समस्या नहीं, व्यवसाय तर्क डेटा के बगल में है। एपीआई खोलें, प्रक्रिया के सामने एक वेब सेवा डालें। आप सबसे नई भाषा का उपयोग करना चाहते हैं, आगे बढ़ें। व्यापार तर्क डेटा के बगल में है।
संग्रहित प्रक्रियाओं का उपयोग करने का एक अन्य कारण यह है कि यह आपके और चुने हुए डेटाबेस के बीच एक मजबूत बंधन बनाता है। इस तरह, आप डीबी की अंतर्निहित कार्यक्षमता का लाभ उठा सकते हैं जिसका आप भुगतान कर रहे हैं (या ओपन सोर्स के मामले में उपयोग कर रहे हैं)। और अनुमान लगाएं, अगर आप अपने आवेदन डीबी को स्वतंत्र बनाने की कोशिश करते हैं तो आपको शायद बग को ट्रैक करने के लिए बहुत मेहनत होगी। Read consistency works differently on each vendor's database.
आप अपने डेटाबेस का अंतर्निहित स्केलेबिलिटी (क्लस्टर, आरएसी - हालांकि वे इसे लागू करते हैं) का लाभ उठा सकते हैं। खुद को लिखने की जरूरत नहीं है।
कोड लिखना कठिन है जो बाइंड वैरिएबल का उपयोग नहीं करता है (यदि आपको उस पर अधिक जानकारी चाहिए तो Google सॉफ्ट पार्स बनाम हार्ड पार्स)।
संस्करण नियंत्रण - जिन कंपनियों ने मैंने संग्रहीत प्रक्रियाओं के लिए हमेशा संस्करण नियंत्रण का उपयोग किया है। आप आमतौर पर कुछ संपादक में संग्रहीत प्रक्रियाओं को लिखते हैं। अधिकांश संपादकों ने अब कम से कम एक प्रमुख संस्करण नियंत्रण प्रणाली के लिए समर्थन में बनाया है।
बाहरी कोड को नेटवर्क पर डेटा खींचना है और फिर इसके साथ काम करना है।
अंत में, सभी प्रक्रियात्मक भाषाओं को समान रूप से नहीं बनाया जाता है। MySQL ने संग्रहीत प्रक्रियाओं का उपयोग करने की क्षमता को अभी जारी किया है और वे आपको कई भाषाओं का उपयोग कर सकते हैं जिनका आप उपयोग कर सकते हैं। मुझे संदेह है कि वे ओरेकल या एसक्यूएल सर्वर के लिए खड़े हैं। मैं सबसे अच्छा कौन नहीं जा रहा हूं क्योंकि मैं ओरेकल के अलावा किसी भी चीज़ में विशेषज्ञ नहीं हूं। ओरेकल के पीएल/एसक्यूएल में बहुत सारी कार्यक्षमता है जो डीबी कर्नेल में अनुकूलित है। मुझे यकीन है कि एमएस एसक्यूएल भी दूसरों के साथ करता है।
आशा है कि यह सहायक होगा (और समझ में आता है - लंबा दिन)।
एसक्यूएल सर्वर का संपादक स्रोत नियंत्रण का समर्थन नहीं करता है। सर्वर भी नहीं है। –
लेकिन विजुअल स्टूडियो करता है। जब तक मैं गलत नहीं हूं, आप उसमें संग्रहीत प्रक्रियाओं को लिख सकते हैं। – user60890
मैं डेटा के खिलाफ व्यापार तर्क रखने के खिलाफ हूं। मैंने कई व्यवसायिक तर्कों के साथ कई संग्रहीत प्रक्रियाओं को देखा है और वे गुप्त हैं। एसक्यूएल (या टीएसक्यूएल) आपके व्यवसाय तर्क लिखने के लिए बनाई गई भाषा नहीं है। अब, आप उल्लेख करते हैं कि MySQL संग्रहित प्रक्रियाओं को विभिन्न भाषाओं में लिखे जाने की अनुमति देता है। इससे कोई फर्क पड़ सकता है। माइक्रोसॉफ्ट एसक्यूएल सर्वर 2005+ भी .NET (सीएलआर) में लेखन स्पॉक्स की अनुमति देता है लेकिन मैंने इसके बारे में अधिक उपयोग या ब्लॉग/पोस्ट नहीं देखा है। निश्चित नहीं है कि क्यों माइक्रोसॉफ्ट इसे उतना ही बढ़ावा नहीं दे रहा है, क्योंकि मुझे लगता है कि यह गतिशील एसक्यूएल और संग्रहीत प्रक्रियाओं के बीच सही संतुलन होगा। –
संग्रहीत प्रक्रियाओं में आवेदन रखने में कई फायदे हैं, और कई का पहले से ही उल्लेख किया गया है।
संग्रहित प्रक्रियाएं एप्लिकेशन और डेटा के बीच अमूर्तता की एक परत के रूप में कार्य करती हैं, और अमूर्तता की परतें शायद ही कभी एक बुरी चीज हैं।
यदि आप डेटाबेस संचालन को कैस्केड करते हैं तो आप पुन: उपयोग के एक निश्चित स्तर को प्राप्त कर सकते हैं। उदाहरण के लिए, Delete_Employee प्रक्रिया, लेनदेन में Delete_Address प्रक्रिया को कॉल कर सकती है, और एप्लिकेशन से एक डेटाबेस अनुरोध के साथ कई अन्य चीजें भी कर सकती है।
संग्रहित प्रक्रियाओं के नीचे दृश्यों की एक परत का उपयोग स्कीमा परिवर्तनों और क्वेरी/प्रदर्शन ट्यूनिंग में शामिल होने से आवेदन को अलग करने के लिए किया जा सकता है।
एक संग्रहित प्रक्रिया परत एक ठोस उद्यम वास्तुकला और ढांचे का एक महत्वपूर्ण हिस्सा है। इन संग्रहीत प्रक्रियाओं में कोई व्यावसायिक तर्क नहीं होना चाहिए, बेशक, उन्हें केवल डेटा के माध्यम से गुजरना चाहिए और इसे कुशल बनाना चाहिए।
इन लाभों को समझने के लिए, एक अनुशासन बनाए रखने के लिए अच्छा अनुशासन और आवेदन में सभी प्रक्रियाओं में समान ग्रैन्युलरिटी है। मैंने कई 100 प्रक्रियाओं के साथ अनुप्रयोगों पर काम किया है। यदि ये सभी प्रश्न कोड में थे, तो डेटा स्तर की सुरक्षा को लागू करने के लिए असंभव नहीं होने पर यह अधिक कठिन होता। संग्रहीत प्रसंस्करण आसानी से उत्पन्न किया जा सकता है। मुझे लगता है कि कुल उत्पादकता बिना संग्रहित प्रक्रियाओं के साथ अधिक है। और निश्चित रूप से संग्रहित प्रक्रियाएं विज्ञापन स्रोत नियंत्रण में होनी चाहिए, क्योंकि यह अन्य सभी डेटाबेस ऑब्जेक्ट्स के मामले में है।
+1 'किसी को किसी को नफरत सहायता की आवश्यकता है। –
एसक्यूएल को स्रोत नियंत्रण में रखा जा सकता है लेकिन कठिन और तेज़ तथ्य यह है कि डेटाबेस पर इसे बदलने में इतना आसान है कि यह काम शायद ही कभी ही करता है। स्रोत नियंत्रण में लिपियों को अभी पुराना हो जाएगा। –
आप खराब कोड प्रबंधन प्रथाओं के साथ खराब एप्लिकेशन डिज़ाइन को उचित ठहराने नहीं कर सकते हैं। – cdonner
मैं संस्करण नियंत्रण के बारे में एक और बात करूंगा। मेरी आखिरी नौकरी में, मैंने एक तीसरी पार्टी पैक की जो कि हर दिन दौड़ती थी और प्रत्येक ऑब्जेक्ट के डीडीएल या कोड की एक प्रति संग्रहित करती थी, अगर पिछली बार इसका बैक अप लिया गया था। यह स्वयं ही प्रक्रियाओं को संग्रहीत किया गया था, इसलिए इसे मैन्युअल रूप से चलाया जा सकता था या ट्रिगर करके, आप इसे कितनी बार चलाने के लिए चाहते थे। यह अपने आप में एक संस्करण नियंत्रण प्रणाली है।
यह एक बहुत अच्छा टूल था और केवल $ 200 था। यह दिखाने के लिए कि यह क्या बदल गया है, यह भी एक diff उपकरण के साथ आया था।
हम काफी कुछ कारणों के लिए कोड के आधार पर व्यापार तर्क के लिए एक उत्पन्न दाल को sprocs में स्विच किया है:
यह वास्तव में इस बात पर निर्भर करता है कि संग्रहीत प्रक्रियाओं को कितनी अच्छी तरह लिखा गया है, है ना? टी-एसक्यूएल और पीएल-एसक्यूएल सी # या कोबोल के रूप में बनाए रखने के लिए केवल gnarly और कठिन हो सकता है यदि चिकित्सक कुछ विचार और देखभाल के साथ कोडिंग नहीं कर रहा है।
मैंने हाल ही में किए गए एन्हांसमेंट में से एक में काम किया है, मैं जानबूझकर एक संग्रहित प्रो में कार्यक्षमता डालता हूं, क्योंकि ज्यादातर कार्यक्षमता संदर्भ में आसान होना चाहता था, बहुत कम बनाए रखने (संग्रहीत प्रक्रिया को डीबी स्तर से बुलाया जा सकता है और क्लाइंट स्तर भी; यदि मैं तर्क को एक अलग परत में डाल दूंगा, तो यह सच नहीं होगा)। मैंने सोचा कि मैंने पीएल-एसक्यूएल को काफी मॉड्यूलर बनाने का अच्छा काम किया है, लेकिन जब TOAD ने इसका विश्लेषण किया, तो 4 में से 3 वर्गों को अच्छे अंक मिले, और आखिरी व्यक्ति को उच्च चक्रीय जटिलता के लिए हथियार मिला। हे, मुझे लगता है कि मैंने अभी अपना खुद का मुद्दा साबित कर दिया है!
कुछ लोग तर्क देंगे कि व्यवसाय तर्क में संग्रहीत प्रक्रियाओं में कोई स्थान नहीं है, और परिणामस्वरूप अनियमित सिस्टम हैं। मैं इंगित करता हूं कि ये तर्क मुख्य रूप से डीडीडी और एन-टियर के दृष्टिकोण से आते हैं जो आवेदन परत के भीतर एक विशिष्ट क्षेत्र में सभी व्यावसायिक तर्कों को घर लेना चाहते हैं। हालांकि यह एक योग्य लक्ष्य है, विचार करने के लायक होने के अन्य दृष्टिकोण हैं। एसपी भी घर व्यापार तर्क से कहीं ज्यादा कर सकते हैं।
संयोग से, ओरेकल दुनिया डीबी पर पीएल/एसक्यूएल कोड में सभी व्यावसायिक तर्क रखने का सर्वोत्तम अभ्यास मानती है, और वे संबंधपरक डेटाबेस के बारे में एक या दो चीज़ों को जानते हैं!
प्रदर्शन:
एस.पी. की इन उपयोगों पर विचार करें। एसपी में एकाधिक एसक्यूएल स्टेटमेंट चलाने के लिए अक्सर उपयोगी होता है और इस प्रकार आपके आवेदन से डीबी को कई राउंड ट्रिप बनाने से बचते हैं, जिसके परिणामस्वरूप कभी-कभी काफी प्रदर्शन सुधार होते हैं।
प्रबंधन बदलें। एसपीएस बनाए रखने और संशोधित करने के लिए सरल हैं, जब तक कि आपके पास संस्करण नियंत्रण और आपकी तैनाती प्रक्रिया के आसपास अनुशासन हो।
एसपी को उत्पादन उत्पादन पर आउटसोर्स के बिना जारी किया जा सकता है, जो 24/7 संचालन में काफी लाभ हो सकता है। बेशक आपको अभी भी रिलीज प्रक्रिया के आसपास कड़े नियंत्रण की जरूरत है।
अमूर्तता की परत। एसपीएस आवेदन से डीबी स्कीमा के ब्योरे को दूर कर सकते हैं, बशर्ते सभी ऐप/डीबी इंटरैक्शन एसपी के माध्यम से हों। यह एक बहुत ही शक्तिशाली अवधारणा हो सकती है। इस बात पर विचार करें कि डीबी की उम्र अक्सर ऐप से बाहर हो जाएगी - ऐप्स आते हैं और जाते हैं, और नवीनतम प्रौद्योगिकियों और वास्तुकला पैटर्न के साथ हर बार फिर से लिखे जाते हैं, लेकिन मूल्यवान डेटा एओन्स के लिए पुराने पुराने संबंध डीबी में रहता है। अक्सर, समान डीबी पर मल्टीप्ल एप्स विकसित होते हैं, भले ही यह कभी भी मूल मंशा न हो। इन परिदृश्यों में एसपी का उपयोग ऐप और डीबी के बीच एक तंग, अच्छी तरह से परिभाषित एपीआई प्रदान करने के लिए किया जाता है, जिसे एकाधिक ऐप्स और यहां तक कि एक ही ऐप के कई संस्करणों के साथ लगातार इंटरैक्शन सुनिश्चित करने के लिए सावधानी से नियंत्रित किया जा सकता है।
डीबी स्कीमा और ऐप के बीच चिंताओं का यह पृथक्करण एप्लिकेशन प्रोग्रामर को सबसे अच्छा करने के लिए स्वतंत्र करता है, जबकि डीबीए के ऐप्स को तोड़ने के बिना समय के साथ स्कीमा को बेहतर बनाने के लिए एक स्वतंत्र हाथ छोड़ते हैं।
जो भी वास्तुकला पैटर्न आप नियोजित करते हैं, एसपी एक मूल्यवान भूमिका निभा सकते हैं। किसी भी डिजाइन से बाहर शासन न करें, और किसी भी उपकरण की तरह, इसका उपयोग करें जहां यह समझ में आता है।
के कई लाभ मैंने इसे चेंज मैनेजमेंट और एबस्ट्रक्शन के लेयर के कारणों के लिए वोट दिया है। आपका प्रदर्शन तर्क लागू नहीं होता है क्योंकि आप इन दिनों एक "कॉल" में एकाधिक एसक्यूएल स्टेटमेंट चला सकते हैं। –
आसान तो क्या? यह सवाल बिना जानने के अर्थहीन है कि किसके साथ तुलना करना है। – SquareCog