दुनिया की सबसे बड़ी आईटी सॉफ्टवेयर कंसल्टिंग फर्मों में से एक में संग्रहीत अभ्यास एक बुरी प्रक्रिया है?

Question

मैं दुनिया के शीर्ष 3 आईटी परामर्श फर्मों में से एक में एक परियोजना पर काम कर रहा हूं, और एक डीबीए द्वारा कहा गया था कि कंपनी के सर्वोत्तम अभ्यास के राज्य संग्रहीत प्रक्रियाएं "सर्वश्रेष्ठ अभ्यास" नहीं हैं। यह मेरे द्वारा सीखी गई हर चीज के विपरीत है।

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

हम चुस्त सॉफ्टवेयर विकास पद्धति का उपयोग कर एक जटिल ऐप विकसित कर रहे हैं। क्या कोई अच्छे कारणों के बारे में सोच सकता है कि वे संग्रहीत प्रोक्स का उपयोग क्यों नहीं करना चाहेंगे? मेरा अनुमान था कि डीबीए उन संग्रहीत प्रोक्स को बनाए नहीं रखना चाहता था, लेकिन इस तरह के डिजाइन निर्णय को सही ठहराने के लिए बहुत अधिक नकारात्मक तरीके हैं।

Comments

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

— रिग

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

— कंसर्नडऑफटुनब्रिजवेल्स

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

— गार्ट क्लैबोर्न

@GaretClaborn लेकिन यह ऐतिहासिक डेटाबेस डेटा के वर्षों और वर्षों की तुलना में एप्लिकेशन परत को फिर से आर्किटेक्ट करने की अधिक संभावना है। किसी भी गैर तुच्छ आवेदन आवेदन पर वैसे भी। और यदि आप करते हैं तो आप संग्रहीत प्रक्रिया को समृद्ध कोड पोर्ट करने में महीनों बिताएंगे। Edgecase स्थितियों को छोड़कर अपनी परियोजना में एक और निर्भरता जोड़ने के लिए बहुत कम लाभ है। वे मौजूद हैं, लेकिन समय के बहुमत इसकी चपलता और कोड का पुन: उपयोग करने के लिए एक और बाधा जोड़ रहा है।

— रिग

एक ऐसी पृष्ठभूमि से आ रहा है जहाँ हमने लगभग विशेष रूप से sps का उपयोग किया है मैं आपको उनसे दूर जाने और ORM फ्रेमवर्क जैसे ORM का उपयोग करने से लाभ बता सकता हूँ। अब तक कई बार व्यावसायिक तर्क प्रक्रिया के भीतर संकुचित हो जाता है। जबकि आप कुछ काम और या थर्ड पार्टी टूल्स के साथ प्रॉक्सेस को वर्जन कर सकते हैं। यह उतना आसान नहीं है जितना कि टीएफएस या जीआईटी जैसे ढांचे के भीतर ऐसा करना होगा। आपका डेटाबेस कोड जो उत्सर्जित होता है, वह आपके RDBMS प्रदाता का अज्ञेय है। इसलिए आप कम सिरदर्द वाले आरडीबीएमएस प्रदाताओं को बाद की तारीख में बदल सकते हैं।

— इवानर

Answer 1

बहुत बड़ी परियोजनाओं पर काम करने के मेरे अनुभव में, आपको यह स्पष्ट करना होगा कि व्यावसायिक तर्क कहाँ रहता है। यदि आप एक ऐसे वातावरण की अनुमति देते हैं जहां व्यक्तिगत डेवलपर व्यावसायिक ऑब्जेक्ट लेयर में या लॉजिस्टिक्स में व्यावसायिक तर्क रख सकते हैं क्योंकि वे फिट दिखाई देते हैं, तो एक बड़ा एप्लिकेशन समझने और बनाए रखने में बहुत मुश्किल हो जाता है।

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

Comments

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

— केविन क्लाइन

@kevin cline: "असंगत स्थिति" को परिभाषित करें। मैं इस बात से सहमत हूं कि संदर्भात्मक अखंडता जैसी डीबी विशेषताएं मूल्यवान हैं और एक एप्लिकेशन त्रुटि की संभावना को बहुत कम करती हैं जिससे गंभीर क्षति होती है। हालांकि, आमतौर पर, "सुसंगत डेटा" की परिभाषा व्यावसायिक नियमों के सही निष्पादन पर निर्भर करती है।

— एरिक जे।

मायो के मिलियन में मेरा मिलियन जोड़ें। वितरित व्यावसायिक तर्क आपको अच्छे अभ्यास के राजमार्ग से दूर ले जाता है, सीधे सीधे लेन के मार्ग में ले जाता है

— निको

+1 व्यावसायिक तर्क डीएएल में रिसने से संग्रहीत प्रक्रियाओं का उपयोग करते समय एक बड़ी चिंता का विषय है।

— सिस्टम डाउन

@ChristopherMahan, मैं कभी भी आपके द्वारा डिज़ाइन किए गए डेटाबेस का उपयोग नहीं करना चाहूंगा। यह एक डेटाबेस परिप्रेक्ष्य से सबसे खराब संभव अभ्यास है। डेटाबेस अक्सर डेटाबेस पर सीधे प्रभावित होते हैं। यह सोचने के लिए अदूरदर्शी है कि कोई व्यक्ति व्यावसायिक परत का उपयोग एक लाख रिकॉर्ड या अन्य चीजें जो समय के साथ होता है, को अपडेट करने के लिए करेगा। आयात आमतौर पर व्यवसाय की परत के माध्यम से नहीं जाते हैं (हां, मैं अपने 21 मिलियन रिकॉर्ड आयात को एक बार व्यापार परत में एक रिकॉर्ड आयात करना चाहता हूं)। जब आप डेटाबेस स्तर पर बाधा नहीं रखते हैं तो धोखाधड़ी बहुत आसान है। खराब डेटा लगभग 100% निश्चित है।

— HLGEM

Answer 2

कुछ अवलोकन

संग्रहीत प्रक्रियाएं आपको कोड का पुन: उपयोग, और एनकैप्सुलेशन (सॉफ्टवेयर विकास के दो स्तंभ) देती हैं,

केवल यदि आप उनका उपयोग उस संदर्भ में सही ढंग से करते हैं जिसमें उनका उपयोग किया जाना है। फ़ंक्शंस (स्ट्रक्चर्ड प्रोग्रामिंग में) या तरीकों (ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग) के बारे में भी यही दावा किया जा सकता है, और फिर भी, हम 1K फ़ंक्शन और मेगा-गधा ऑब्जेक्ट देखते हैं।

कलाकृतियों आपको उन लाभों को नहीं देती हैं। उन कलाकृतियों का उचित उपयोग है जो उन लाभों को देते हैं।

सुरक्षा (आप किसी व्यक्तिगत संग्रहित खरीद पर अनुमति दे सकते हैं / रद्द कर सकते हैं),

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

आपको SQL इंजेक्शन के हमलों से बचाएं,

यह SPs के लिए विशिष्ट नहीं है क्योंकि आप पैरामीटर किए गए SQL स्टेटमेंट और इनपुट स्क्रबिंग के साथ समान स्तर की सुरक्षा प्राप्त कर सकते हैं। मैं एसपी का उपयोग उन लोगों के अलावा करूंगा, हालांकि, "गहराई में सुरक्षा" के रूप में ।

और गति के साथ भी मदद करें (हालांकि कि डीबीए ने कहा कि SQL सर्वर 2008 से शुरू होता है कि नियमित एसक्यूएल प्रश्नों को भी संकलित किया जाता है यदि वे पर्याप्त बार चलाए जाते हैं)।

यह अत्यधिक डेटाबेस विक्रेता विशिष्ट है, लेकिन सामान्य तौर पर आपका डीबीए सही है। SQL स्टेटमेंट (या तो स्टैटिक या पैराट्राइज्ड) संकलित होते हैं। एसपी मदद करते हैं यदि आप चाहते हैं / डेटा एकत्र करने और गणना करने की आवश्यकता है जो आप सरल एसक्यूएल बयानों के साथ नहीं कर सकते हैं, लेकिन कसकर एसक्यूएल के साथ एकीकृत हैं और ऐप सर्वर पर राउंड-ट्रिप को वारंट नहीं करते हैं।

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

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

हम चुस्त सॉफ्टवेयर विकास पद्धति का उपयोग कर एक जटिल ऐप विकसित कर रहे हैं।

चपलता सॉफ्टवेयर इंजीनियरिंग प्रक्रियाओं और आवश्यकता प्रबंधन, और प्रौद्योगिकियों के साथ नहीं है।

क्या कोई अच्छे कारणों के बारे में सोच सकता है कि वे संग्रहीत प्रोक्स का उपयोग क्यों नहीं करना चाहेंगे?

गलत प्रश्न

प्रश्न गलत है और यह पूछने के बराबर है कि "क्या कोई अच्छा कारण है जो गोटो का उपयोग नहीं करते हैं"? मैं निकल्ज़ विर्थ के साथ इस विषय पर दीक्जस्त्र की तुलना में अधिक हूं। मैं समझ सकता हूं कि दिज्क्स्ट्रा की भावना कहां से आई है, लेकिन मेरा मानना ​​है कि यह सभी मामलों में 100% लागू है। स्टोर procs और किसी भी तकनीक के साथ भी।

एक उपकरण तब अच्छा होता है जब उसका उपयोग अपने इच्छित उद्देश्य के लिए किया जाता है, और जब वह किसी विशेष कार्य के लिए सबसे अच्छा उपकरण होता है। अन्यथा इसका उपयोग करना इस बात का संकेत नहीं है कि उपकरण गलत है, लेकिन यह है कि क्षेत्ररक्षक को पता नहीं है कि वह क्या कर रहा है।

उचित सवाल यह है कि "किस प्रकार के संग्रहित प्रक्रिया उपयोग पैटर्न से बचा जाना चाहिए।" या, "मुझे किन परिस्थितियों में संग्रहीत प्रक्रियाओं का उपयोग करना चाहिए (या नहीं करना चाहिए") । एक प्रौद्योगिकी का उपयोग नहीं करने के कारणों की तलाश बस उपकरण पर दोष डाल रही है क्योंकि इंजीनियरिंग की जिम्मेदारी को स्क्वायर में रखने का विरोध किया जाता है जहां यह इंजीनियर में है।

दूसरे शब्दों में, यह एक पुलिस-आउट या अज्ञानता का बयान है।

मेरा अनुमान था कि डीबीए उन संग्रहीत प्रोक्स को बनाए नहीं रखना चाहता था, लेकिन इस तरह के डिजाइन निर्णय को सही ठहराने के लिए बहुत अधिक नकारात्मक तरीके हैं।

इसके बाद वे जो कर रहे हैं, वे उनके खराब इंजीनियरिंग निर्णयों के परिणामों को उन उपकरणों पर पेश कर रहे हैं, जिनका वे खराब उपयोग करते थे।

आपके मामले में क्या करना है?

मेरा अनुभव है, जब रोम में, जैसा कि रोमन करते हैं ।

यह लड़ाई मत करो। यदि आपकी कंपनी के लोग खराब स्थिति के रूप में स्टोर प्रॉक्स को लेबल करना चाहते हैं, तो उन्हें जाने दें। हालांकि, सलाह दी जाती है कि यह उनकी इंजीनियरिंग प्रथाओं में एक लाल झंडा हो सकता है।

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

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

अच्छे इंजीनियर ऐसे सामान्य तरीकों से बुरे व्यवहार के रूप में चीजों को लेबल नहीं करते हैं। वे समस्या को देखते हैं, उपयुक्त उपकरण का चयन करते हैं, व्यापार-नापसंद करते हैं। दूसरे शब्दों में, वे इंजीनियरिंग करते हैं।

उनका उपयोग न करने के बारे में मेरी राय

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

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

• डेटाबेस को केवल अपने स्टोर प्रोक्स से युक्त जगह न बनाएं। आपके स्टोर के प्रोक्स को उसी तरह से माना जाना चाहिए जैसे आप अपने C # या जावा सोर्स कोड को मानते हैं। यही है, स्रोत आपके स्टोर के टेक्स्ट की परिभाषा को नियंत्रित करता है। प्रैंक को स्टोर करने वाले लोग नियंत्रित स्रोत - बुलक्रैप नहीं हो सकते हैं, वे सिर्फ यह नहीं जानते हैं कि वे किस खूनी नरक के बारे में बात कर रहे हैं।

कैसे / कहाँ उनका उपयोग करने में मेरी राय

• आपके एप्लिकेशन को ऐसे डेटा की आवश्यकता होती है, जिन्हें कई प्रश्नों या विचारों से ट्रांसप्लांट या एकत्र किया जाना चाहिए। आप अनुप्रयोग से db में उसे लोड कर सकते हैं। यहाँ आपको एक प्रदर्शन विश्लेषण करना है क्योंकि a) डेटाबेस इंजन अधिक कुशल होते हैं जो ऐप सर्वर को इन कामों को करने में करते हैं, लेकिन b) ऐप सर्वर क्षैतिज रूप से बड़े पैमाने पर (कभी-कभी) आसान होते हैं।

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

किसी भी एसक्यूएल स्टेटमेंट को चलाने के लिए किसी वैध स्टोर की जरूरत नहीं है , एक अलग यूजरनेम / अकाउंट और कनेक्शन पूल (अत्यधिक निगरानी और हतोत्साहित उपयोग के साथ) के माध्यम से जाता है।

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

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

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

क्या यह एक स्थायी समाधान बन जाता है या नहीं, यह उस विशेष क्षण में देखे जाने वाले अवरोधों के लिए विशिष्ट है।

आशा है ये मदद करेगा।

Comments

यह एक बहुत अच्छा जवाब है।

— 23 फरवरी को yfeldblum

अच्छा जवाब है, लेकिन क्या यह विडंबना है? "सामान्यीकरण सभी पेंच अप की जननी है।"

— शयनकक्ष

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

— luis.espinal

+1 के लिए "खराब अभ्यास के रूप में चीजों की विशिष्ट लेबलिंग आमतौर पर अक्षम प्रोग्रामर के टन के साथ संगठनों में की जाती है।" - वहाँ के माध्यम से रहते थे, जिसमें एक देव प्रबंधक द्वारा मेरे चेहरे को बताया गया था कि उसने सोचा कि मेरे पास एक मुश्किल समस्या का एक बड़ा समाधान है, लेकिन अगर वह मुझे इसे लागू करने की अनुमति देने के लिए देखा गया था, तो यह बाढ़ के द्वार खोल देगा। द मपेट्स।

— जूलिया हेवर्ड

@ शाने तुम सही हो। हालाँकि मेरा मानना ​​है कि यह उत्तर जो बताने की कोशिश कर रहा है, वह है कुछ इंजीनियरों की प्रवृत्ति, जो खराब प्रैक्टिस कार्ड पर कॉल करके अपने ज्ञान या विश्लेषण की कमी का बहाना करते हैं। उत्तर हम में से अधिक अनुभवहीन के लिए कुछ सुधार देख सकता है, हालांकि।

— सीजर हर्नांडेज़

Answer 3

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

(संग्रहीत कार्यविधियाँ) आपको SQL इंजेक्शन के हमलों से बचाती हैं

यह वास्तव में आप की रक्षा करने वाली पैराड्राइज्ड क्वेरी है, जिसे आप आसानी से सादे पाठ एसक्यूएल क्वेरी में कर सकते हैं।

Comments

और अगर आपका संग्रहित खरीद किसी स्ट्रिंग पैरामीटर के साथ-साथ किसी भी प्रकार के डायनामिक sql का उपयोग कर रहा है, तो आप ठीक उसी जगह पर हैं जहाँ आपने शुरुआत की थी।

— जेएफओ

अंतर यह है कि एक्सेस अनुमति को प्रक्रिया के आधार पर संग्रहीत प्रक्रियाओं के लिए सेट किया जा सकता है, पैरामीटर किए गए SQL प्रश्नों के लिए आपको प्रोग्रामर की पवित्रता पर भरोसा करना होगा + "blablabla"क्योंकि आपको सादे एसक्यूएल की अनुमति नहीं है, और जहां नियंत्रण समाप्त होता है।

— कोडर

मैंने कभी भी "आपको एक निश्चित डीबी के संबंध में" तर्क नहीं समझा है। आप कितनी बार अपना कार्यक्रम लेते हैं और इसे पूरी तरह से अलग डेटाबेस में स्थानांतरित करते हैं?

— मेसन व्हीलर

@MasonWheeler - +1 हर बार। किसी भी पर्याप्त रूप से बड़ी परियोजना में, आपका एप्लिकेशन किसी दिए गए DB उत्पाद के स्वास्तिक के खिलाफ लिखा जा रहा है। एक और DB में परिवर्तित करना एक प्रमुख काम बन जाता है, इससे कोई फर्क नहीं पड़ता क्योंकि नए DB में अलग-अलग विषमताएँ होंगी!

— माइकल कोहेन

@HLGEM - लेकिन COTS की दुनिया में, कई DBs शुरू में (वास्तव में, आप संगत DB का चयन करते हैं) में उपलब्ध हैं। यह नहीं है कि आप पोर्ट करते हैं, यह है कि आप अलग-अलग बैक-एंड का समर्थन करते हैं, जो पोर्ट करने की तुलना में पूरी तरह से अलग जानवर है।

— माइकल कोहेन

Answer 4

जिन कारणों से मैं संग्रहित procs से सहमत हूं उनमें से कुछ सर्वोत्तम अभ्यास नहीं हैं।

• व्यापार और अनुप्रयोग तर्क डेटाबेस में नहीं कोड में होना चाहिए। डीबी में तर्क देना चिंता का सबब है।
• आप अपने पारंपरिक यूनिट टेस्ट प्रोजेक्ट्स में कोड के रूप में स्टोर किए गए प्रॉपर को बाकी एप्लिकेशन लॉजिक के साथ टेस्ट नहीं कर सकते।
• जब मैं कोड लिख रहा होता हूं तो मुझे पहले प्रोग्रामिंग का परीक्षण करने के लिए अनुकूल होने के रूप में संग्रहीत प्रोक्स नहीं मिलते हैं।
• जब आप अपने IDE में अपना प्रोग्राम डीबग कर रहे होते हैं, तो संग्रहीत कोड अनुप्रयोग कोड के रूप में संग्रहित करने में आसान नहीं होते हैं।
• वर्जनिंग कंट्रोल / सोर्स कंट्रोल ऑफ एसपी बनाम नॉर्मल कोड

Comments

आप बस के रूप में आसान हो सकता है परीक्षण संग्रहीत प्रक्रियाओं पर पहली प्रोग्रामिंग।

हम्म, अच्छी तरह से ... 1) डीबी संग्रहीत प्रक्रियाओं का उपयोग जरूरी नहीं है कि व्यापार तर्क उनमें डाला जा रहा है। 2) स्टोर किए गए प्रॉपर यूनिट टेस्ट के लिए सबसे आसान चीजें हैं। 3) स्टोर प्रॉक्स जरूरी नहीं कि टेस्ट-फर्स्ट प्रैक्टिस का कंडक्टिव हो, सच है, लेकिन ऐसा भी नहीं है कि जो कुछ कंप्यूटेबल हो, वह टेस्ट-फर्स्टेड हो। 4) डिबगिंग एक मुद्दा नहीं होना चाहिए क्योंकि स्टोर प्रॉपर में एसक्यूएल स्टेटमेंट्स और कर्सर को आसानी से सत्यापित करने के अलावा और कुछ नहीं होना चाहिए। इसके अलावा, डिबगिंग को पहले परीक्षण के द्वारा लिया जाना चाहिए और कोड में एसक्यूएल स्टेटमेंट को डीबग करना चाहिए, और फिर स्टोर प्रोक्स में चले गए ... बस IMO btw।

— luis.espinal

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

— gbjbaanb

2) यूनिट परीक्षण पर संग्रहीत procs। अन्य इकाई परीक्षण ढाँचों के बारे में आइडीके, लेकिन कम से कम एमएस टेस्ट (विजुअलस्टडियो.टेस्टटूलस यूनीटस्टिंग) के साथ, संग्रहीत खरीद पर किसी भी एस्टर तरीके को चलाने के लिए कम से कम एक डीबी कनेक्शन की आवश्यकता होती है, जो परिभाषा के अनुसार इसे एक इकाई की तुलना में अधिक एकीकरण परीक्षण बनाता है। परीक्षा। और एक संग्रहित खरीद एक वैश्विक, डेटाबेस स्तर पर डेटाबेस के बारे में स्थिति का संदर्भ दे सकती है। ये नकली-सक्षम नहीं हो सकते हैं या इनका इंटरफेस नहीं हो सकता है।

— टी। वेबस्टर

+1 इसके अलावा, संग्रहीत कार्यविधियाँ (pl / sql, t-sql, plpgsql, आदि) बहुत ही क्लिंक और वर्बोज़ हैं। डेटाबेस कनेक्शन बनाने और डेटाबेस के बाहर व्यावसायिक तर्क को संभालने के लिए स्क्रिप्टिंग भाषा का उपयोग करना मेरे लिए बहुत आसान है।

Answer 5

संग्रहीत प्रक्रियाएं आपको कोड का पुन: उपयोग, और एनकैप्सुलेशन (सॉफ्टवेयर विकास के दो स्तंभ) देती हैं,

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

आपको SQL इंजेक्शन के हमलों से बचाएं,

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

और गति के साथ भी मदद करें (हालांकि कि डीबीए ने कहा कि SQL सर्वर 2008 से शुरू होता है कि नियमित एसक्यूएल प्रश्नों को भी संकलित किया जाता है यदि वे पर्याप्त बार चलाए जाते हैं)।

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

केवल एक संग्रहीत प्रक्रिया, IMHO, उपयोग करने के लिए कारण है जब आप एक जटिल, बहु का मंचन क्वेरी कि कई स्रोतों से collated खींचती करना चाहिए है। एसपी में निम्न-स्तरीय निर्णय तर्क नहीं होना चाहिए, और उन्हें कभी भी अन्यथा सरल क्वेरी को एनकैप्सुलेट नहीं करना चाहिए । कोई लाभ नहीं है और केवल कई कमियां हैं।

अपने डीबीए को सुनो। वह जानता है कि क्या हो रहा है।

Comments

Red Gate में SQL Server के लिए एक उत्पाद SQL Source Control है , लेकिन मैं मानता हूं, लॉजिक को संग्रहीत procs में धकेलना यह सुनिश्चित करने का एक शानदार तरीका है कि आपके पास महत्वपूर्ण तर्क किसी भी प्रकार के संस्करण नियंत्रण में नहीं है।

— कार्सन 63000

@ ग्रेफेड - "मुझे अभी तक एसपी के लिए स्रोत नियंत्रण देखना है" - क्या आप मुझसे मजाक कर रहे हैं? एक स्टोर खरीद सिर्फ एक खूनी पाठ फ़ाइल है जिसे आप अपने डेटाबेस इंजन में अपलोड करते हैं (जो इसे लेता है, इसे संकलित करता है और इसे निष्पादन के लिए स्थापित करता है।) हर जगह मैंने काम किया है जो कि procs संग्रहीत किया गया है, हम स्टोर proc स्रोत में स्टोर करते हैं। सीवीएस, साफ़ करें या जो भी SCM उपयोग में था। यह कहना कि स्टोर प्रोक्स को सोर्स-नियंत्रित नहीं किया जा सकता है (क्योंकि वे डीबी में हैं) मेरे एप्लीकेशन सोर्स कोड (जावा, सी # या जो भी हो) को नियंत्रित करने जैसा नहीं कहा जा सकता क्योंकि यह उत्पादन में संकलित और तैनात है।

— luis.espinal

@ luis.espinal: मैंने यह नहीं कहा कि वे स्रोत नियंत्रण में नहीं हो सकते । मैंने केवल इतना कहा कि मुझे विशेष रूप से एसपी के इतिहास को बनाए रखने के लिए एक उपकरण का पता नहीं था, डेटाबेस में उस इतिहास को बनाए रखने का अर्थ है। कृपया मुझ पर शेख़ी न करें क्योंकि आपने कुछ गलत किया है।

— ग्रेफेड

सभी opur संग्रहीत procs स्रोत conrtrol के अंतर्गत हैं, सिर्फ इसलिए कि आपने अतीत में खराब दृष्टांत देखे हैं इसका मतलब यह नहीं है कि वे संग्रहीत procs का उपयोग करने में अंतर्निहित हैं।

— HLGEM

@ luis.espinal यह विशिष्ट है कि संग्रहीत प्रक्रिया के स्रोत को डेटाबेस से बाद में पुनर्प्राप्त किया जा सकता है? यदि हां, तो आपके पास बस एक उपकरण हो सकता है जो इसे नियमित रूप से खींचता है, और खरोंच से एक इंस्टॉलेशन को फिर से बनाने के लिए अन्य टूलिंग है। यह सुनिश्चित करने के लिए कि यह सटीक है, एक बार एक समय में करें।

Answer 6

यह आधिकारिक पंक्ति थी जब मैंने कुछ साल पहले बिग फाइव में से एक के लिए काम किया था। तर्क यह था कि चूंकि एसपी विशेष कार्यान्वयन (पीएल / एसक्यूएल बनाम टी / एसक्यूएल बनाम ...) से बंधे हैं, वे अनावश्यक रूप से प्रौद्योगिकी विकल्पों को सीमित करते हैं।

टी / एसक्यूएल से पीएल / एसक्यूएल में एक बड़ी प्रणाली के प्रवास के माध्यम से रहने के बाद, मैं तर्क को समझ सकता हूं। मुझे लगता है कि यह बहुत हद तक एक तरह से कैंडर है - वास्तव में कितने स्थान एक डेटाबेस से दूसरे पर एक चक्कर लगाते हैं?

Comments

@ मूल्य: एक उद्यम समाधान के लिए आप शायद सही हैं। यदि आप पैकेज्ड सॉफ्टवेयर बना रहे हैं, तो जैसे ही आप MSSQL पर शिप करेंगे आपकी सबसे बड़ी संभावना यह होगी कि वह ओरेकल पर चले।

— एरिक जे।

@ विदेश: बहुत सच। जहां मैं अभी हूं, हम टन का उपयोग करते हैं और अगर वे MSSQL नहीं चाहते हैं तो लोगों को 'नहीं' बताएं। ऐसा करने में सक्षम होना अच्छा है।

— डेवई

@ मूल्य: क्या बिक्री टीम का कहना है कि आप "हाँ" कह सकते हैं?

— एरिक जे।

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

@ एरिक जे: हाँ, लेकिन एक बार वे देखते हैं कि लागत उनके कमीशन के लिए क्या करेगी, अनुरोध थोड़े दूर चला जाता है।

— डेवई

Answer 7

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

मान लीजिए कि आपके पास एक संग्रहीत कार्यविधि है जो एक डेटासेट लौटाता है जिसका आप उपयोग करना चाहते हैं, आप इसे भविष्य में संग्रहीत प्रक्रियाओं में कैसे उपयोग कर सकते हैं? इसके लिए SQL सर्वर पर तंत्र बहुत अच्छे नहीं हैं। EXEC INTO ... केवल एक या दो स्तर पर काम करता है) नेस्टिंग (मैं अब भूल जाता हूं)। या आपको एक कार्य तालिका को पूर्व-परिभाषित करना होगा और इसकी प्रक्रिया को बंद करना होगा। या आपको एक अस्थायी तालिका बनाने और प्रक्रिया को पॉप्युलेट करने की आवश्यकता है। लेकिन क्या होगा अगर दो लोग एक अस्थायी तालिका को दो अलग-अलग प्रक्रियाओं में एक ही चीज़ कहते हैं जो उन्होंने एक ही समय में उपयोग करने की योजना नहीं बनाई है? किसी भी सामान्य प्रोग्रामिंग भाषा में, आप किसी फ़ंक्शन या पॉइंट से किसी ऑब्जेक्ट / वैश्विक संरचना को उनके बीच साझा की गई किसी वस्तु पर वापस लौट सकते हैं (केवल उन कार्यात्मक भाषाओं को छोड़कर, जहां आप डेटा संरचना को केवल वैश्विक संरचना को बदलने के विरोध में लौटाएंगे ... )

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

त्रुटि से निपटने के बारे में कैसे? SQL सर्वर में कई त्रुटियां हैं जो संग्रहीत प्रक्रिया को तुरंत निष्पादित करने से रोकती हैं और कुछ जो कि डिस्कनेक्ट करने के लिए मजबूर करती हैं। 2005 के बाद से कोशिश / पकड़ है लेकिन अभी भी कई त्रुटियां हैं जिन्हें पकड़ा नहीं जा सकता है। साथ ही त्रुटि हैंडलिंग कोड पर कोड डुप्लिकेट के साथ भी यही होता है और आप वास्तव में अपवादों को आसानी से पास नहीं कर सकते हैं या उन्हें उच्च स्तर तक आसानी से सबसे प्रोग्रामिंग भाषाओं में बबल कर सकते हैं .....

इसके अलावा बस गति। डेटासेट पर बहुत सारे ऑपरेशन SET उन्मुख नहीं हैं। यदि आप पंक्ति उन्मुख सामान करने की कोशिश करते हैं, तो या तो आप एक कर्सर का उपयोग करने जा रहे हैं, या आप "कर्सर" का उपयोग करने जा रहे हैं (जब डेवलपर्स अक्सर प्रत्येक पंक्ति को एक-एक करके क्वेरी करते हैं और सामग्री को कर्सर की तरह @ चर में संग्रहीत करते हैं। .. हालांकि यह प्रायः FORWARD_ONLY कर्सर की तुलना में धीमा है)। SQL Server 2000 के साथ मेरे पास कुछ ऐसा था जो मुझे मारने से पहले 1 घंटे के लिए चल रहा था। मैंने उस कोड को पर्ल में फिर से लिखा और यह 20 मिनट में समाप्त हो गया। जब एक स्क्रिप्टिंग भाषा जो प्रदर्शन में सी स्मोक एसक्यूएल से 20-80x धीमी होती है, तो आपके पास निश्चित रूप से एसक्यूएल में कोई व्यवसाय लेखन पंक्ति उन्मुख संचालन नहीं होता है।

अब SQL सर्वर में CLR एकीकरण होता है और यदि आप CLR संग्रहीत कार्यविधि का उपयोग करते हैं, तो इनमें से बहुत सारे मुद्दे दूर हो जाते हैं। लेकिन कई DBA को पता नहीं है कि .NET प्रोग्राम कैसे लिखें या सुरक्षा चिंताओं के कारण CLR को बंद करें और Transact SQL के साथ चिपके रहें .... साथ ही CLR के साथ आपके पास अभी भी एक कुशल तरीके से कई प्रक्रियाओं के बीच डेटा साझा करने के मुद्दे हैं। ।

इसके अलावा सामान्य तौर पर सबसे कठिन बात यह है कि डेटाबेस है। यदि आपके सभी व्यावसायिक तर्क डेटाबेस में हैं, तो जब डेटाबेस बहुत धीमा हो जाता है तो आपके पास समस्याएँ होने वाली हैं। यदि आपके पास एक व्यावसायिक परत है, तो आप प्रदर्शन को बढ़ावा देने के लिए अधिक कैशिंग और अधिक व्यापार सर्वर जोड़ सकते हैं। परंपरागत रूप से विंडोज़ / लिनक्स स्थापित करने और .NET / Java चलाने के लिए एक अन्य सर्वर एक अन्य डेटाबेस सर्वर खरीदने और अधिक SQL सर्वर को लाइसेंस देने से बहुत सस्ता है। SQL सर्वर में अब अधिक क्लस्टरिंग समर्थन है, हालांकि, मूल रूप से इसका वास्तव में कोई भी नहीं था। इसलिए यदि आपके पास बहुत सारा पैसा है, तो आप क्लस्टरिंग जोड़ सकते हैं या यहां तक ​​कि कई लॉग केवल प्रतियां पढ़ने के लिए कुछ लॉग शिपिंग भी कर सकते हैं। लेकिन कुल मिलाकर यह केवल कैश या कुछ के पीछे लिखने की तुलना में बहुत अधिक खर्च होगा।

ट्रांसेक्ट-एसक्यूएल सुविधाओं को भी देखें। स्ट्रिंग हेरफेर? मैं किसी भी दिन जावा स्ट्रिंग क्लास / टोकनराइज़र / स्कैनर / रेगेक्स कक्षाएं ले लूंगा। हैश टेबल्स / लिंक्ड सूची / आदि। मैं जावा संग्रह चौखटे, आदि ले जाऊंगा ... और .NET के लिए समान ... दोनों C # और जावा दोनों तरह से Transact SQL की तुलना में अधिक विकसित भाषाएं हैं ... Transact-SQL के साथ हेक कोडिंग मुझे C की जलन होती है। ।

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

साथ ही संग्रहीत कार्यविधियाँ सुरक्षा के लिए अच्छी हैं। आप अंतर्निहित तालिकाओं तक सभी पहुंच में कटौती कर सकते हैं और केवल संग्रहीत प्रक्रियाओं के माध्यम से पहुंच की अनुमति दे सकते हैं। एक्सएमएल जैसी कुछ आधुनिक तकनीकों के साथ आप संग्रहीत प्रक्रियाएं कर सकते हैं जो बैच अपडेट करती हैं। तब सभी एक्सेस को संग्रहीत प्रक्रियाओं के माध्यम से नियंत्रित किया जाता है ताकि जब तक वे सुरक्षित / सही न हो जाएं डेटा में अधिक अखंडता हो सकती है।

SQL इंजेक्शन तर्क वास्तव में इतना लागू नहीं होता है क्योंकि हमने प्रोग्रामिंग लैंग्वेज साइड पर प्रश्नों को पैरामीटर बना दिया है। वास्तव में भी पहले से ही मानकीकृत प्रश्नों से पहले थोड़ा प्रतिस्थापन ("" "," '") ने अधिकांश समय के रूप में अच्छी तरह से काम किया (हालांकि अभी भी चालें हैं कि स्ट्रिंग के अंत में जाने के लिए उपयोग करने के लिए जो आप चाहते हैं)।

कुल मिलाकर मुझे लगता है कि डेटा को क्वेरी / अपडेट करने के लिए SQL और Transact SQL बड़ी भाषाएँ हैं। लेकिन किसी भी प्रकार के लॉजिक को कोड करने के लिए, स्ट्रिंग हेरफेर (या हेक फ़ाइल मैनिपुलेशन) .... आपको आश्चर्य होगा कि आप xp_cmdshell .... के साथ क्या कर सकते हैं। मैं एक भविष्य की जगह खोजने की उम्मीद कर रहा हूं जो ज्यादातर संग्रहीत प्रक्रियाओं का उपयोग नहीं करता है। कोड के रख-रखाव के दृष्टिकोण से वे एक बुरा सपना हैं। यदि आप प्लेटफ़ॉर्म स्विच करना चाहते हैं, तो भी क्या होता है (हालाँकि वास्तव में यदि आप Oracle / DB2 / Sybase / Sqase Server / etc के लिए भुगतान करते हैं। आप हर एक मालिकाना एक्सटेंशन का उपयोग करके आप उन सभी को प्राप्त कर सकते हैं जो आपको मदद कर सकते हैं। ..)।

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

Comments

मैं मदद नहीं कर सकता, लेकिन पूरे सेट-उन्मुख बनाम प्रक्रियात्मक मुद्दे पर विचार के लिए भोजन की पेशकश कर सकता हूं। मैंने उन सभी प्रकार के मामलों में उपयोग किए जाने वाले डेटाबेस कोसर्स को देखा है जहां यह दृष्टिकोण सिर्फ पागल था। मैंने व्यक्तिगत रूप से स्पष्ट कर्सर-आधारित एसक्यूएल (ओरेकल पीएल / एसक्यूएल, उस विशेष मामले में) को एक सेट-ओरिएंटेड क्वेरी के साथ बदल दिया है और देखा कि परिणाम 8 मिनट के बजाय एक दूसरे के तहत वापस आते हैं। 1,000 लाइन कर्सर कोड को विच्छेद करने में मुझे 30 मिनट का समय लगा और इसे "प्राप्त" किया। परिणामी SQL क्वेरी संक्षिप्त, सुरुचिपूर्ण, सरल थी। लोग अपने डेटाबेस सर्वर की शक्ति को बहुत कम बार और बहुत जल्दी दूर करते हैं।

— क्रेग

Answer 8

आप सर्वर पर संग्रहीत कार्यविधियों का संस्करण कैसे देते हैं?

यदि आप संस्करण नियंत्रण से सर्वर पर संग्रहीत प्रक्रियाओं को फिर से तैयार करते हैं, तो आप संग्रहीत निष्पादन योजना को उड़ा देते हैं।

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

हालांकि संग्रहीत कार्यविधियाँ गैर-पोर्टेबल हैं, न तो SQL सामान्य रूप से है (कभी-कभी ऑरेकल डेट हैंडलिंग - uggghhh) देखा जाता है।

इसलिए, यदि आप पोर्टेबिलिटी चाहते हैं, तो आंतरिक डेटा एक्सेस एपीआई बनाएं। आप इसे फंक्शन कॉल की तरह कॉल कर सकते हैं, और आंतरिक रूप से आप जो भी चाहते हैं, जो भी चाहते हैं, उसमें पैरामीटराइज्ड क्वेश्चन के साथ बना सकते हैं, और इसे वर्जन-नियंत्रित किया जा सकता है।

Comments

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

— luis.espinal

@BarryBrown यह काम नहीं करता है अगर लोगों के पास सर्वर तक सीधे पहुंच है और संग्रहीत प्रक्रियाओं को बदल सकता है। मैं एक प्रक्रिया है कि SPs देखता है, या प्रत्येक उपयोग करने से पहले एक जांच होगा ...

— क्रिस्टोफर महान

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

— क्रेग

अतीत में मैंने जो कुछ किया है, उनमें से एक डेटाबेस सर्वर के विकास का उदाहरण व्यक्तिगत डेवलपर के वर्कस्टेशन पर रखना है, या यदि यह संभव नहीं था, तो कम से कम डेटाबेस के "देव" और "उत्पादन" उदाहरण हैं। , और सभी DDL और DML स्क्रिप्ट, साथ ही नमूना डेटा और लोड स्क्रिप्ट स्रोत ट्री में अपनी स्वयं की निर्देशिका के अंतर्गत रहते थे, और डेटाबेस उन लिपियों से नियमित रूप से MAKE फ़ाइल का उपयोग करके बनाया गया था। देवता एकल संग्रहीत प्रोक बनाने के लिए एनएमके का उपयोग करने में सक्षम थे, साथ ही साथ। यदि वे इसे स्रोत नियंत्रण में नहीं रखते हैं, तो यह उन पर गायब हो जाएगा, और वे इसे जानते थे।

— क्रेग

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

— क्रेग

Answer 9

यह मेरे द्वारा सीखी गई हर चीज के विपरीत है।

आपको अधिक बाहर निकलने की आवश्यकता हो सकती है। [मुसकान] गंभीर रूप से, संग्रहीत प्रॉक्स कम से कम 10 वर्षों से गिरावट पर हैं। क्लाइंट-सर्वर की जगह n-tier बहुत सुंदर है। गिरावट केवल OO भाषाओं जैसे जावा, C #, पायथन आदि को अपनाने से तेज हुई है।

यह कहना है कि संग्रहीत procs में अभी भी उनके प्रस्तावक और अधिवक्ता नहीं हैं - लेकिन यह एक लंबी चर्चा और बहस है। यह नया नहीं है, और संभवतः अभी भी काफी समय से चल रहा है; IMO, संग्रहीत प्रोक्स के विरोधी स्पष्ट रूप से जीत रहे हैं।

संग्रहीत प्रक्रियाएं आपको कोड का पुन: उपयोग, और एनकैप्सुलेशन (सॉफ्टवेयर विकास के दो स्तंभ) देती हैं

सच सच। लेकिन, इसलिए एक शालीनता से तैयार की गई ओओ परत है।

सुरक्षा (आप किसी संग्रहीत संग्रह पर अनुमति दे सकते हैं / रद्द कर सकते हैं)

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

आपको SQL इंजेक्शन के हमलों से बचाएं

पैरामीट्रिक प्रश्नों को करने से अधिक नहीं। जो आपको वैसे भी करने की आवश्यकता है।

और गति के साथ भी मदद करें (हालांकि कि डीबीए ने कहा कि SQL सर्वर 2008 से शुरू होता है कि नियमित एसक्यूएल प्रश्नों को भी संकलित किया जाता है यदि वे पर्याप्त बार चलाए जाते हैं)।

मुझे लगता है कि MSSQL 7 या 2000 में शुरू हुआ था। संग्रहित बनाम इनलाइन SQL प्रदर्शन पर बहुत सारी बहसें, माप और गलत सूचनाएँ आई हैं - मैं यह सब YAGNI के तहत करता हूँ। और, यदि आपको इसकी आवश्यकता है, तो परीक्षण करें।

हम चुस्त सॉफ्टवेयर विकास पद्धति का उपयोग कर एक जटिल ऐप विकसित कर रहे हैं। क्या कोई अच्छे कारणों के बारे में सोच सकता है कि वे संग्रहीत प्रोक्स का उपयोग क्यों नहीं करना चाहेंगे?

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

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

Comments

प्रदर्शन करने के लिए एक बहुत कुछ है यदि आपको सरल सामान करने के लिए डेटाबेस से विशाल डेटासेट को स्थानांतरित नहीं करना है। यदि आवश्यक हो तो मापें, और अनुकूलित करें।

यकीनन। संग्रहीत प्रक्रियाओं का उपयोग स्केलपेल की तरह किया जा सकता है। यह एक पूर्ण गारंटी है कि डेटाबेस सर्वर के अंदर I / O डेटाबेस सर्वर और आपके मध्य स्तरीय के बीच I / O से अधिक बैंडविड्थ है। और आप तेजी से लिखने के लिए नहीं जा रहे हैं, और अधिक कुशल डेटा डेटाबेस सर्वर में लिखा डेटाबेस इंजन देवों की तुलना में आपके मध्य स्तरीय में कोड शामिल करते हैं। यदि आप ज्वाइन करने के लिए अपने मध्य स्तरीय डेटा की 1,000,000 पंक्तियों को स्थानांतरित कर रहे हैं, जो मैंने निश्चित रूप से देखा है, तो आपको केवल ठगना चाहिए ... यह उन लोगों की तरह है जो दावा करते हैं कि आपको "अपना रोलबैक कोड लिखना चाहिए।" पागलपन।

— क्रेग

अपने डेटाबेस सर्वर को कम मत समझना। इसका सही इस्तेमाल करना सीखें।

— क्रेग

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

— मार्क ब्रैकेट

पूरी तरह से सच है, और मैं वास्तव में एसक्यूएल के पक्ष में बहस कर रहा था विशेष रूप से स्पार्क्स के लिए बहस करने से ज्यादा। लेकिन तब एसक्यूएल आपके अनिवार्य कोड में एम्बेडेड होना जरूरी नहीं है कि खुशी की कुंजी, या तो, सही है? जो अक्सर पूरे ORM डिबेट में शामिल हो जाता है, जो तब मुझे ORM- संचालित db पहुँच बनाम SQL के उपयोग का तरीका सीखने के बीच प्रदर्शन तुलना की ओर इशारा करता है। मैं उन दोनों प्रणालियों के बारे में देख और सुन चुका हूँ जहाँ, कहते हैं, Oracle सलाहकारों ने डेटाबेस सर्वर से सभी भारों को संभव रखने की सिफारिश की है, जो कि भारी (और मोटे तौर पर महंगे!) मध्यम स्तर पर abysmal प्रदर्शन के लिए अग्रणी है ।

— क्रेग

Answer 10

उपरोक्त सभी मामलों को ध्यान में रखते हुए, मैं एक और जोड़ना चाहूंगा। सपा की पसंद लोगों की पसंद पर भी निर्भर करती है।

मैं व्यक्तिगत रूप से निराश महसूस करता हूं जब लोग सपा में बहुत जटिल तर्क रखते हैं और मेरा मानना ​​है कि ऐसे सपा को बनाए रखने और बहस करने के लिए बहुत जटिल है। यहां तक ​​कि कई मामलों में डेवलपर को समस्या का सामना करना पड़ता है जब एसपी की तुलना में कोड (पीछे भाषा भाग) में डिबगिंग अधिक आसान होती है।

एसपी का उपयोग केवल सरल संचालन के लिए किया जाना चाहिए। खैर यह मेरी पसंद है।

Answer 11

मैं कुछ pro- और con- मुद्दों को संग्रहीत procs के साथ कवर करना चाहता हूं। हम उन्हें बड़े पैमाने पर LedgerSMB के साथ उपयोग करते हैं , और हमारा नियम है, कुछ बहुत ही विशिष्ट विस्तार के साथ, "यदि यह एक क्वेरी है, तो इसे एक संग्रहित खरीद बनाएं।"

ऐसा करने का हमारा कारण क्रॉस-लैंग्वेज क्वेरी पुन: उपयोग को सुविधाजनक बनाना था। ईमानदारी से ऐसा करने का कोई बेहतर तरीका नहीं है।

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

तो कोन तरफ।

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

2. हां, किसी भी गतिशील एसक्यूएल को करने पर इंट्रा-स्पोक एसक्यूएल इंजेक्शन होना संभव है। इस क्षेत्र में अति-आत्मविश्वास होना एक बुरी बात है, और फलस्वरूप इस क्षेत्र में सुरक्षा का महत्वपूर्ण अनुभव होना चाहिए।

3. ऊपर # 1 कारण के लिए संग्रहीत प्रक्रियाओं के साथ इंटरफेस में कुछ हद तक समस्याग्रस्त हैं, लेकिन बड़ी संख्या में क्लाइंट ऐप शामिल होने पर यह बहुत बड़ा दुःस्वप्न बन सकता है।

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

सकारात्मकता पर। मान लें कि आप उपरोक्त समस्याओं को हल कर सकते हैं:

1. सेट ऑपरेशन में स्पष्टता बढ़ने की संभावना। यह विशेष रूप से सच है यदि आपकी क्वेरी बहुत बड़ी या बहुत लचीली है। यह भी बढ़ाया testability की ओर जाता है।

2. अगर मेरे पास इस क्षेत्र में पहले से काम करने वाला एक सेवा लोकेटर है, तो मुझे संग्रहीत कार्यविधियाँ विकास की गति को गति देती हैं क्योंकि वे एप्लिकेशन डेवलपर को डीबी चिंताओं और इसके विपरीत से मुक्त करते हैं। इससे सही करने में कुछ कठिनाइयाँ हैं लेकिन ऐसा करना मुश्किल नहीं है।

3. क्वेरी फिर से उपयोग करें।

ओह और कुछ चीजें जो आपको लगभग एक सपा में कभी नहीं करनी चाहिए:

1. गैर-लेन-देन का तर्क। आपने ईमेल भेजा था कि ऑर्डर भेज दिया गया था, लेकिन लेन-देन वापस आ गया ... या अब आप ऑनलाइन आने के लिए ईमेल सर्वर को जारी रखने की प्रतीक्षा कर रहे हैं .... या इससे भी बदतर है कि आप अपने लेन-देन को केवल इसलिए वापस कर दें क्योंकि आप उस तक नहीं पहुंच सकते ईमेल सर्वर…।

2. छोटे प्रश्नों के बहुत से एक साथ टकराए, प्रक्रियात्मक तर्क के साथ छिड़का ...।

Comments

दृढ़ता से सहमत हों, फिर से: गैर-लेन-देन वाले कबाड़ को संग्रहीत प्रक्रियाओं से बाहर रखना। उस ईमेल उदाहरण में, ईमेल संदेश को एक कतार में छोड़ दिया जाना चाहिए और अतुल्यकालिक, वैसे भी सेवित होना चाहिए। लोड के तहत एक विशाल प्रदर्शन हिट और कायरतापूर्ण व्यवहार के लिए खुद को स्थापित करने के बारे में बात करें, जिससे आपके डेटाबेस लेनदेन आपके मेल सर्वर की प्रतिक्रिया पर निर्भर हैं? ओह!

— क्रेग

Answer 12

तुम किसके लिए काम करते हो?

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

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

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

बाड़ के दोनों ओर (बहुत) अधिक चर्चा के लिए, कोडिंग हॉरर पर चर्चा पढ़ें । FWIW मैं सपा के लिए वकालत करने वालों की तरफ झुकता हूं।

Comments

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

— yfeldblum

इसके अलावा, आपने 2004 से एक लेख को जोड़ा, IMHO परिदृश्य तब से काफी बदल गया है। OR / M बहुत अधिक आम हो गए हैं। Ruby / Rails ActiveRecord, MS लिनक और EF, अजगर के लिए Django, आदि के साथ बाहर आया

— ब्रुक

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

— HLGEM

@HLGEM मैं आपके द्वारा लाए गए किसी भी बिंदु पर आपत्ति नहीं करता । लेकिन मुझे उत्तर की थीसिस पर आपत्ति है कि प्राथमिक कारण डीबीए ने आवेदन में तर्क दिया हो सकता है क्योंकि वह एक सलाहकार है और ग्राहक को पेंच करना चाहता है। यह संग्रहीत प्रक्रियाओं का उपयोग करने के लिए किसी व्यक्ति की नैतिक पसंद को उसकी पसंद के लिए खड़ा करता है। मेरी राय में, दोनों पक्षों में तकनीकी तर्क हैं , और दोनों पक्षों के तर्क आवेदन से आवेदन, प्रौद्योगिकी से प्रौद्योगिकी, कंपनी से कंपनी, उद्योग से उद्योग तक भिन्न होंगे। और मैं पहले मकसद तलाशने से पहले योग्यता की तलाश करूंगा।

— 23 फरवरी को yfeldblum

उन्होंने कहा कि वह एक कंसल्टिंग फर्म के लिए काम करते हैं। ग्राहक की साइट पर तैनात कोड बनाम संग्रहीत प्रक्रियाओं पर अधिक नियंत्रण बनाए रखना एक बहुत ही वैध कारण है कि यह उनका "सर्वोत्तम अभ्यास" हो सकता है। यह "ग्राहक को पेंच" करने के लिए नहीं हो सकता है, लेकिन अच्छी तरह से अधिक नियंत्रण का मुद्दा हो सकता है।

— जेसी

Answer 13

डेटाबेस ब्रांडों को स्विच करना और समान संग्रहीत प्रक्रियाओं का उपयोग करना बहुत मुश्किल है।

आपकी टीम के पास DBA नहीं है और कोई भी व्यक्ति sql के साथ कुछ नहीं करना चाहता है।

यह एक प्रोग्रामर बनाम DBA pissing प्रतियोगिता से अधिक कुछ नहीं है।

Answer 14

IMO यह निर्भर करता है। संग्रहीत प्रक्रियाओं में अपना स्थान होता है, लेकिन वे एक सर्वोत्तम अभ्यास नहीं हैं, और न ही उन्हें हर कीमत पर बचा जाना चाहिए। एक स्मार्ट डेवलपर जानता है कि किसी दिए गए स्थिति का ठीक से मूल्यांकन कैसे करें और निर्धारित करें कि संग्रहीत प्रक्रिया का उत्तर है या नहीं। व्यक्तिगत रूप से मैं पूर्वनिर्धारित रिपोर्टों या इसी तरह के अलावा शायद संग्रहीत प्रक्रियाओं के बजाय किसी तरह का एक ORM (यहां तक ​​कि कच्चे Linq जैसे Sql के लिए एक मूल) का उपयोग करने का प्रशंसक हूं, लेकिन फिर से यह वास्तव में एक मामला-दर-मामला आधार है।

Comments

डाउनवोटर्स टिप्पणी करेंगे।

— सैंडरॉक

Answer 15

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

उस ने कहा, मैं उन कंपनियों को जानता हूं जो डेटाबेस में रहने वाले पीएल / एसक्यूएल पैकेजों में सभी व्यापारिक तर्क डालकर बहुत अच्छा करती हैं। वे बहुत बड़े अनुप्रयोग नहीं हैं, लेकिन या तो तुच्छ नहीं; 20K-100K LOC कहते हैं। (पीएल / एसक्यूएल एसक्यूएल की तुलना में उस तरह के सिस्टम के लिए बेहतर है, इसलिए यदि आप केवल टी-एसक्यूएल जानते हैं, तो आप शायद अब अविश्वास में अपना सिर हिला देंगे ...)

Answer 16

यह एक और बिंदु है जिसका उल्लेख अभी तक नहीं किया गया है:

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

इसलिए यदि आप डेटा-ट्रांसफर-ऑब्जेक्ट DTO और DAO लेयर को स्वचालित रूप से बनाने के लिए एक टूल का उपयोग करना चाहते हैं (जैसे कि लाइफ़यर का "सर्विस बिल्डर" करता है), तो आप आसानी से ऐसा नहीं कर सकते।

इसके अलावा, डेटा स्रोत SP होने पर, हाइबरनेट जैसे ORM वास्तव में ठीक से काम नहीं कर सकते हैं। डेटा एक्सेस केवल-सबसे अच्छा पढ़ा जाता है।

Comments

यह दिलचस्प है कि कोड जनरेशन टूल्स में जाहिरा तौर पर ऐसा कठिन समय होता है, जिसमें यह पता चलता है कि कोई संग्रहीत प्रक्रिया परिणाम सेट करती है या नहीं, जब संग्रहित प्रक्रिया को ही इससे कोई परेशानी नहीं होती है।

— क्रेग

Answer 17

प्रोग्रामिंग एकल, मैं संग्रहीत प्रक्रियाओं को लिखने का विरोध नहीं कर सकता ।

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

इसलिए, मेरे पास एक प्रक्रिया है logIn। जब आप लॉग इन करते हैं, तो आप हमेशा पास करते हैं usernameऔर password। उत्तीर्ण परिणाम पूर्णांक है userId।

जब logInएक संग्रहीत कार्यविधि होती है, तो अब मैं लॉगिन पर किए जाने वाले अतिरिक्त कार्य को जोड़ सकता हूं जो कि प्रारंभिक लॉग इन के समान ही होता है। मुझे एक संग्रहीत कार्यविधि में SQL तर्क की एक श्रृंखला मिली है जो संग्रहीत कार्यविधि में आसानी से लिखी जा सकती है (कॉलिंग) पर्यावरण FETCH) -> (परिणाम प्राप्त करें) -> (पर्यावरण FETCH कॉलिंग) श्रृंखला आपको तब करना होगा जब आप अपना तर्क सर्वर पक्ष लिखते हैं।

Answer 18

मैं यह भी बताना चाहता हूं कि संग्रहीत कार्यविधियाँ सर्वर पर CPU समय का उपयोग करती हैं। बहुत कुछ नहीं, लेकिन कुछ। कार्य प्रक्रिया में किए गए कुछ काम ऐप में किए जा सकते हैं। डेटा लेयर की तुलना में ऐप लेयर को स्केल करना ज्यादा आसान है।

Comments

एक डेटाबेस को स्केल करना मुश्किल है?

— जेएफओ

यह कम से कम काफी महंगा है (जब तक कि MySQL पर नहीं) और कई स्थानों पर मैंने काम किया है एक और SQL सर्वर एंटरप्राइज एडिशन लाइसेंस प्राप्त करना दांतों को खींचने जैसा है

— बेन एफ।

स्केलिंग डेटाबेस कहानी के ऐप लेयर एंड को स्केल करने से ज्यादा कठिन नहीं है

— ब्रायन ओग्डेन

Answer 19

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

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

Fwiw, यह हमारा इरादा है कि स्कीमा अपडेट होने पर SPs को हटा दिया जाए। लेकिन, जैसा कि कॉर्पोरेट विकास में सब कुछ है, हम देखेंगे कि क्या कभी ऐसा होता है! [मुस्कराहट]

Answer 20

मैं सिर्फ एक संक्षिप्त अवलोकन करना चाहता था कि मैं संग्रहीत प्रक्रियाओं का उपयोग करने की सिफारिश कैसे करूंगा। मुझे नहीं लगता कि वे एक बुरा व्यवहार हैं, और दूसरों ने कहा है कि उनका उपयोग उचित परिस्थितियों में किया जाना चाहिए।

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

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

अन्य कार्य डेटाबेस की मजबूत डेटा मॉडल का पालन करने वाले एप्लिकेशन की जरूरतों को पूरा करने के लिए डेटा में हेरफेर करते हैं, मुझे लगता है कि फिर व्यापार तर्क वाले किसी अन्य परत में संग्रहीत किया जाना चाहिए। संक्षेप में, संगति के लिए डेटाबेस विशिष्ट डेटा हेरफेर संग्रहीत कार्यविधियों का उपयोग कर सकता है, जहां संगति डेटाबेस अखंडता स्कीमा मॉडल के अतीत का विस्तार करती है।

Answer 21

संग्रहीत प्रक्रिया "मेरे लिए" OLAP "केवल पढ़ने के लिए" संचालन के लिए अनुकूल है, दुर्लभ उपयोग।

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

मेरे लिए महत्वपूर्ण बात यह है कि डिबग संग्रहीत प्रक्रियाओं की तुलना में व्यावसायिक परत में डिबग करना आसान है।

Comments

आपने कुछ धारणाएँ बनाई हैं: ओपी को ओएलएपी (प्रश्न में कहा नहीं गया) की आवश्यकता है; उस प्लेटफ़ॉर्म का उपयोग किया जा रहा है जिसमें जावा एप्लिकेशन सर्वर हैं (चूंकि टैग SQL सर्वर के बारे में नहीं है)। आप जवाब भी कुछ भी नहीं है कि अन्य 22 जवाब पहले से ही कवर नहीं किया था

— एडम Zuckerman

मैं सिर्फ यह कह रहा था कि यदि मैं एक नई परियोजना शुरू करता हूं, तो संग्रहीत प्रक्रिया का उपयोग शायद ही कभी केवल एक व्यक्तिगत पसंद केवल पढ़ने के लिए किया जाएगा। मुझे डेटा लेयर के बजाय बिजनेस लॉजिक लेयर पर अधिकांश कोडिंग करना अधिक सुविधाजनक लगता है।

— जेजोन लुबटन

इससे पहले किए गए 24 से अधिक अंकों में कुछ भी स्पष्ट नहीं होता है और इससे पहले के 24 उत्तरों में समझाया गया है, शायद ही कोई 4 साल पुराने सवाल को

— टालने

Answer 22

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

अपने उपकरणों को समझदारी से चुनें और आप लंबे समय में खुद को चोटिल होने से बचाएंगे।

Comments

यदि आप नीचे जा रहे हैं तो ऐसा करें, लेकिन कम से कम क्यों समझाएं।

— निको

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

— gbjbaanb

आप डेटाबेस के अलावा अपने संग्रहीत डेटा पर ट्रांसफ़ॉर्म सेट कहां करते हैं?

— क्रिस ट्रेवर्स 3