क्या ऐसी कई चीजें हैं जो बहुत अधिक संग्रहीत प्रक्रियाओं के रूप में हैं?क्या आपके पास बहुत अधिक संग्रहित प्रक्रियाएं हो सकती हैं?
मुझे पता है कि आपके पास कितनी संख्या हो सकती है, लेकिन क्या यह कोई प्रदर्शन या वास्तुशिल्प कारण है जो सैकड़ों, हजारों को नहीं बनाना है ??
मेरे लिए उस सैकड़ों या हजारों स्टोर प्रक्रिया की सबसे बड़ी सीमा रखरखाव है। हालांकि यह प्रत्यक्ष प्रदर्शन हिट नहीं है, यह एक विचार होना चाहिए। यह एक वास्तुकला स्टैंड प्वाइंट है, आपको न केवल आवेदन के शुरुआती विकास के लिए, बल्कि भविष्य में बदलाव और रखरखाव की योजना बनाना है।
कहा जा रहा है कि आपको अपने आवेदन की आवश्यकता के अनुसार डिजाइन/निर्माण करना चाहिए। यद्यपि हाइबरनेट, एनएचबीर्नेट, .NET LINQ के साथ मैं कोड में जितनी अधिक स्टोर प्रक्रियाओं को तर्क रखने की कोशिश करता हूं, और गति केवल एक कारक होने पर इसे डेटाबेस में डाल देता है।
मैं जब तक आप उन्हें नाम के रूप में लगता है uspXXX और नहीं नाम से देखने spXXX प्रत्यक्ष है, तो कोई नकारात्मक पहलू होगा - हालांकि आप procs सामान्यीकरण के बारे में सोच सकते हैं आप हजारों अगर ...
तुम्हारा मतलब क्या इस तथ्य के अलावा कि जब आप डेटाबेस में बदलाव करते हैं तो आपको उन सभी को बनाए रखना होगा? यह मेरे लिए बड़ा कारण है। बेहतर होना बेहतर है जो सैकड़ों की तुलना में कई परिदृश्यों को संभाल सकता है जो केवल एक को संभाल सकता है।
मैं बस उल्लेख करता हूं कि ऐसी सभी चीजों के रखरखाव के साथ एक मुद्दा बन जाता है। कौन जानता है कि वे सभी क्या हैं और वे किस उद्देश्य की सेवा करते हैं? साल के अंत में क्या होता है जब वे एक विरासत प्रणाली के कलाकृतियों हैं कि कोई भी याद नहीं कर सकता कि वे क्या हैं लेकिन गड़बड़ी से डरते हैं?
मुझे लगता है कि मुख्य बात यह है कि यह संभव नहीं है, लेकिन यह किया जाना चाहिए। वैसे भी सिर्फ एक विचार है।
जैसा कि अन्य ने कहा है, यह वास्तव में प्रबंधन पहलू पर आता है। थोड़ी देर के बाद, यह घास के मैदान में प्रोवर्बियल सुई खोजने में बदल जाता है। यह और भी अधिक है जब जगह पर खराब नामकरण मानदंड हैं ...
मेरा सवाल यह है कि आप कुछ प्रकार के मिडलवेयर मंच का उपयोग क्यों नहीं कर रहे हैं यदि आप सैकड़ों या हजारों संग्रहीत प्रक्रियाओं के बारे में बात कर रहे हैं?
मुझे पुराने फैशन पर कॉल करें, लेकिन मैंने सोचा कि डेटाबेस को केवल डेटा रखना चाहिए और कार्यक्रम व्यवसाय तर्क निर्णय लेने वाला होना चाहिए।
बढ़ जाएगा जो वास्तव में सच नहीं है। ऐसी कई चीजें हैं जिन्हें डेटाबेस में ऑफलोड किया जा सकता है जो वास्तव में वहां बेहतर तरीके से किया जाता है। कुछ स्पष्ट चीजें उच्च स्तर की बाधा जांच हो सकती हैं (कुछ ऐसा होना चाहिए जो कोई फर्क नहीं पड़ता कि कितने ऐप्स टेबल तक पहुंचते हैं)। –
मेरी इच्छा है कि मैं टिप्पणियों को ऊपर उठा सकूं :) – Constantin
नहीं, मुझे पता नहीं है। हालांकि, आपके पास उनके लिए एक अच्छा नामकरण सम्मेलन होना चाहिए। उदाहरण के लिए, उन्हें usp_ से शुरू करना ऐसा कुछ है जो बहुत सी चीज करना पसंद करता है (sp_ से शुरू होने से तेज़)।
हो सकता है कि आपकी रिपोर्टिंग स्पॉक्स usp_reporting_ होनी चाहिए, और आपकी बोस्नेस ऑब्जेक्ट्स usp_bussiness_ होना चाहिए, आदि। जब तक आप उन्हें प्रबंधित कर सकते हैं, उनमें से बहुत से समस्या होने में कोई समस्या नहीं होनी चाहिए।
यदि वे बहुत बड़े हो जाते हैं तो आप डेटाबेस को कई डेटाबेस में विभाजित करना चाहते हैं। इससे अधिक तार्किक अर्थ हो सकता है और डेटाबेस आकार और ऐसे में मदद कर सकता है।
यदि आपके पास बहुत से संग्रहीत प्रक्रियाएं हैं, तो आप पाएंगे कि आप स्वयं को एक डेटाबेस में जोड़ रहे हैं - उनमें से कुछ को आसानी से स्थानांतरित नहीं किया जा सकता है।
अपने आप को एक डेटाबेस में ले जाना अच्छा डिजाइन नहीं है।
इसके अलावा, यदि आपके पास डेटाबेस पर और व्यापार परत में व्यावसायिक तर्क है तो रखरखाव एक समस्या बन जाता है।
ओरेकल डेटाबेस में आप समूह से संबंधित प्रक्रियाओं के साथ पैकेज का उपयोग कर सकते हैं।
उनमें से कुछ और आपका नामस्थान मुक्त हो जाएगा।
नरक हाँ, आप बहुत अधिक हो सकते हैं। मैंने कुछ साल पहले एक प्रणाली पर काम किया था जिसमें 10,000 प्रोसेस की तरह कुछ था। यह पागल था। सिस्टम लिखने वाले लोगों को वास्तव में प्रोग्राम नहीं करना था, लेकिन उन्हें पता था कि बुरी तरह से संरचित प्रोसेस को कैसे सही किया जाए, इसलिए उन्होंने प्रोसेस में लगभग सभी आवेदन तर्क डाले। कुछ procs हजारों लाइन के लिए भाग गया। गड़बड़ी का प्रबंधन एक दुःस्वप्न था।
बहुत अधिक (और मैं आपको रेत में एक विशिष्ट रेखा नहीं खींच सकता) शायद खराब डिजाइन का संकेतक है। इसके अलावा, जैसा कि अन्य ने इंगित किया है, बड़ी मात्रा में प्रोसेस का उपयोग किये बिना ग्रैनुलर डेटाबेस इंटरफ़ेस प्राप्त करने के बेहतर तरीके हैं।
मेरे पास एक वाणिज्यिक SQL Server 2005 उत्पाद में 200 से कम है, जो कुछ नई रिपोर्टों के लिए अगले कुछ दिनों में लगभग 10-20 तक बढ़ने की संभावना है।
जहां संभव हो मैं 'subroutine' sprocs लिखता हूं, ताकि जब भी मैं खुद को 3 या 4 समान कथनों को एक साथ दो से अधिक स्पॉक्स में डालूं, तो यह समय है कि वे कुछ कथन को सबराउटिन में बदल दें, अगर आप देखते हैं कि मैं क्या देखता हूं मतलब है।
मैं सभी व्यावसायिक तर्कों को करने के लिए स्पॉक्स का उपयोग नहीं करता हूं, इसलिए मैं सिर्फ कुछ भी कर रहा हूं जो 'लेनदेन' के रूप में देखा जा सकता है - इसलिए जहां मेरा ग्राहक कोड (डेल्फी में लेकिन जो भी हो) अजीब डालने या खुद को अपडेट कर सकता है, जैसे ही कुछ चीजों को अपडेट करने या 'एक बार में' डालने की आवश्यकता होती है, यह एक स्पोक के लिए समय है।
मैं पठनीयता में सहायता करने के लिए एक सरल, कच्चे नामकरण परंपरा है (और रखरखाव में!)
उत्पाद का कोड नाम 'राहेल' है, इसलिए हम
RP_whatever - these are general sprocs that update/insert data,
- or return small result sets
RXP_whatever - these are subroutine sprocs that server as 'functions'
- or workers to the RP_ type procs
REP_whatever - these are sprocs that simply act as glorified views almost
- they don't alter data, they return potentially complex result sets
- for reporting purposes, etc
XX_whatever - these are internal test/development/maintenance sprocs
- that the client application (or the local dba) would not normally use
है नामकरण मनमाना है , यह सिर्फ SQL सर्वर का उपयोग करता है sp_ उपसर्ग से भिन्न करने में मदद करने के लिए है।
मुझे लगता है कि अगर मुझे पता चला कि मेरे पास डेटाबेस में 400-500 स्पॉक्स हैं, तो मैं चिंतित हो सकता हूं, लेकिन कुछ सौ समस्या तब तक कोई समस्या नहीं है जब तक आपके पास प्रत्येक स्पोक की किस तरह की गतिविधि की पहचान करने के लिए एक प्रणाली हो के लिए जिम्मेदार। मैं अपने उच्च स्तरीय प्रोग्रामिंग भाषा में स्कीमा परिवर्तनों का पीछा करने की कोशिश करने के बजाय कुछ सौ sprocs (जहां SQL सर्वर उपकरण आप निर्भरता आदि खोजने में मदद कर सकते हैं) में स्कीमा परिवर्तन का पीछा करना चाहते हैं।
हाँ आप कर सकते हैं।
किसी विशेष बात यह है कि बहुत ज्यादा शायद आप गलत कर रहे हैं। बहुत अधिक कॉन्फ़िगरेशन फ़ाइलें, स्क्रीन पर बहुत सारे बटन ...
अन्य आरडीबीएमएस के लिए बात नहीं कर सकता है लेकिन पीएल/एसक्यूएल का उपयोग करने वाले ओरेकल एप्लिकेशन को तार्किक रूप से प्रक्रियाओं और कार्यों को कैस्केडिंग अमान्यता को रोकने और कोड प्रबंधित करने के लिए संकुल में होना चाहिए बेहतर।
हाँ, आप बहुत से संग्रहीत प्रक्रियाओं को बहुत अधिक कर सकते हैं।
नामकरण सम्मेलन वास्तव में इसके साथ मदद कर सकते हैं।उदाहरण के लिए, यदि आपके पास नामकरण सम्मेलन है जहां आपके पास हमेशा टेबल नाम और InsUpd है या प्राप्त करें, तो दाएं संग्रहीत प्रक्रिया को ढूंढने के लिए यह बहुत आसान है। यदि आपके पास किसी प्रकार का मानक नामकरण सम्मेलन नहीं है तो यह वास्तव में एक ही चीज़ के दो (या अधिक) प्रक्रियाओं के साथ आना आसान होगा।
यह एक मानकीकृत नामकरण परंपरा बिना निम्न में से एक जोड़े को खोजने के लिए आसान होगा ... usp_GetCustomersOrder, CustomerOrderGet_sp, GetOrdersByCustomer_sp, spOrderDetailFetch, GetCustOrderInfo, आदि
एक और बात क्या हो रहा है जब आप एक बहुत कुछ है शुरू होता है कि संग्रहीत प्रक्रियाओं का यह है कि आपके पास कुछ संग्रहित प्रक्रियाएं होंगी जिनका उपयोग कभी नहीं किया जाता है और कुछ जो कि शायद ही कभी उपयोग किए जाते हैं ... यदि आपके पास संग्रहीत प्रक्रिया उपयोग को ट्रैक करने का कोई तरीका नहीं है तो आप या तो बहुत से अप्रयुक्त हैं प्रक्रियाओं ... या इससे भी बदतर, जो आपको लगता है उससे छुटकारा पाने के लिए कभी भी उपयोग नहीं किया जाता है और बाद में पता चलता है कि यह साल में या एक बार तिमाही में उपयोग किया जाता है। :(
जेफ
आप सभी कि कोड कहीं पर रखना होगा।
आप (मैं व्यक्तिगत रूप से उन्हें एहसान करते हैं, पर बहुत सी नहीं) सब पर संग्रहित प्रक्रियाओं के लिए जा रहे हैं, तो आप हो सकता है और साथ ही उन्हें के रूप में ज्यादा उपयोग करने के रूप में आप की जरूरत है। कम से कम सभी डेटाबेस तर्क एक ही स्थान पर है। नकारात्मक पक्ष यह है वहाँ संग्रहीत procs से भरा एक बाल्टी के लिए आम तौर पर बहुत संरचना नहीं है।
आपका कॉल! :)
लेकिन यदि आप गतिशील रूप से कुछ कोड उत्पन्न करते हैं, तो आपके पास उतना ही नहीं है! – MattMcKnight
जब आपके पास सौनाम नामकरण सम्मेलन नहीं है, तब तक अद्यतित दस्तावेज और पर्याप्त यूनिट परीक्षण उन्हें व्यवस्थित रखें।
मुझे लगता है कि यहां गहरा सवाल है- उस कोड को और कहां जाना चाहिए? मानक एसक्यूएल के माध्यम से डेटा तक सुविधाजनक पहुंच प्रदान करने के लिए दृश्यों का उपयोग किया जा सकता है। SQL उत्पन्न करने के लिए अधिक शक्तिशाली एप्लिकेशन भाषाएं और पुस्तकालयों का उपयोग किया जा सकता है। संग्रहीत प्रक्रियाओं में डेटा की प्रकृति को अस्पष्ट करना पड़ता है और एक प्रणाली में अमूर्तता, जटिलता और रखरखाव की अनावश्यक परत पेश करता है।
मूल एसक्यूएल उत्पन्न करने के लिए ऑब्जेक्ट रिलेशनल मैपिंग टूल्स की शक्ति को देखते हुए, किसी भी प्रणाली जो संग्रहीत प्रक्रियाओं पर अत्यधिक निर्भर है, विकसित करने के लिए कम कुशल होने जा रही है। ओआरएम के साथ, लिखने के लिए बस बहुत कम कोड है।
मेरा पहला बड़ा प्रोजेक्ट ऑब्जेक्ट रिलेशनल मैपर के साथ विकसित किया गया था जो डेटाबेस को सारणीबद्ध करता था, इसलिए हमने सब कुछ ऑब्जेक्ट उन्मुख किया और बग को ठीक करना और ठीक करना आसान था और सभी डेटा एक्सेस और व्यापार तर्क के बाद से बदलाव करना आसान था सी # कोड था, हालांकि, जब यह जटिल चीजें करने के लिए आया तो सिस्टम धीमा महसूस कर रहा था, इसलिए हमें उन चीजों के आसपास काम करना पड़ा या परियोजना को पुन: आर्किटेक्ट करना पड़ा, खासकर जब ओआरएम को डेटाबेस में जटिल जोड़ना पड़ा।
मैं अब एक अलग कंपनी पर काम कर रहा हूं जिसमें "हमारे अनुप्रयोग डेटाबेस के सामने हैं" और इसका लाभ और नुकसान है। हमारे पास वास्तव में तेज़ एप्लिकेशन हैं क्योंकि सभी डेटा ऑपरेशन संग्रहीत प्रक्रियाओं पर किए जाते हैं, यह मुख्य रूप से SQL Server 2005 का उपयोग कर रहा है, लेकिन, जब कोई बदलाव करने की बात आती है, या सॉफ़्टवेयर को ठीक करना मुश्किल होता है क्योंकि आपको दोनों को बदलना होता है, सी # कोड और एसक्यूएल संग्रहीत प्रक्रियाएं, इसलिए यह दो बार काम करने की तरह है, जब मैंने ओआरएम का उपयोग किया था, तो आपने एसक्यूएल, मैनेजमेंट स्टूडियो और अन्य टूल्स में रिफैक्टरिंग या दृढ़ता से टाइप की गई वस्तुओं को बहुत मदद नहीं की है, लेकिन आम तौर पर आप इस तरह से अधिक समय बिताते हैं ।
तो मैं कहूंगा कि परियोजना की ज़रूरतों पर निर्भर करते हुए, यदि आप वास्तव में जटिल व्यापार डेटा रखने के लिए नहीं जा रहे हैं, तो आप शायद संग्रहीत प्रक्रियाओं का उपयोग करने से बच सकते हैं और एक ओआरएम का उपयोग कर सकते हैं जो डेवलपर जीवन को आसान बनाता है।यदि आप प्रदर्शन के बारे में चिंतित हैं और आपको संग्रहीत प्रक्रियाओं का उपयोग करने के बजाय सभी संसाधनों को सहेजने की आवश्यकता है, तो निश्चित रूप से, मात्रा आपके द्वारा डिज़ाइन किए गए आर्किटेक्चर को अपनाने से रोकती है, इसलिए यदि आप हमेशा सीआरयूडी परिचालनों के लिए प्रक्रियाओं को संग्रहीत करते हैं तो एक्समैपल के लिए आपको एक की आवश्यकता होगी प्रविष्टियों के लिए, एक अद्यतन के लिए, एक हटाने के लिए, एक चुनने के लिए और एक सूची के लिए एक क्योंकि यह सबसे आम परिचालन है, यदि आपके पास 100 व्यावसायिक वस्तुएं हैं, तो इन 4 को गुणा करें और आपको सबसे बुनियादी प्रबंधन के लिए 400 संग्रहीत प्रक्रियाएं मिलेंगी अपनी वस्तुओं पर संचालन इसलिए, हाँ, वे बहुत अधिक हो सकते हैं।
मेरे लिए, बहुत से संग्रहीत प्रक्रियाओं का उपयोग करके आप PHP API के समतुल्य कुछ की ओर ले जाते हैं। हजारों वैश्विक कार्यों जिनमें एक दूसरे के साथ मिलकर एक दूसरे के साथ कुछ भी नहीं हो सकता है। उनके बीच संबंध बनाने का एकमात्र तरीका कुछ नामकरण सम्मेलन होना है जहां आप प्रत्येक फ़ंक्शन को मॉड्यूल नाम के साथ उपसर्ग करते हैं, PHP में mysql_ फ़ंक्शंस के समान। मुझे लगता है कि यह बनाए रखना बहुत मुश्किल है, और सब कुछ सुसंगत रखने के लिए बहुत मुश्किल है। मुझे लगता है कि संग्रहित प्रक्रियाएं उन चीजों के लिए अच्छी तरह से काम करती हैं जिन्हें वास्तव में सर्वर पर होने की आवश्यकता होती है। एक साधारण चयन क्वेरी के लिए संग्रहीत प्रक्रिया, या यहां तक कि एक साझा क्वेरी के साथ एक चुनिंदा क्वेरी शायद दूर तक जा रही है। केवल संग्रहीत प्रक्रियाओं का उपयोग करें जहां आपको वास्तव में डेटाबेस सर्वर पर संभालने के लिए उन्नत तर्क की आवश्यकता होती है।
पूरी तरह से सहमत हैं - स्कीमा परिवर्तन होने पर हजारों एसपी का रखरखाव अनावश्यक हो जाता है। – stephbu
मैं इस विचार को दूसरा स्थान देता हूं, मैं हजारों स्टोर प्रक्रियाओं से नफरत करता हूं। –
क्या आपके संग्रहित प्रक्रियाओं में व्यावसायिक तर्क के नॉट्स के साथ समाप्त होने का जोखिम नहीं है या "स्पेगेटी" कोड को बनाए रखने के लिए मुश्किल है यदि आपके पास कुछ बहुउद्देश्यीय स्पॉक्स हैं? लक्षित संग्रहित प्रक्रियाएं जो प्रत्येक एक कार्य को केवल बनाए रखने के लिए बहुत आसान हैं .. – Rob