क्या संग्रहीत कार्यविधियाँ त्रि-स्तरीय पृथक्करण का उल्लंघन करती हैं?


41

मेरे कुछ सहयोगियों ने मुझे बताया है कि डेटाबेस में संग्रहीत कार्यविधियों में व्यावसायिक तर्क का होना त्रिस्तरीय पृथक्करण वास्तुकला का उल्लंघन करता है, क्योंकि डेटाबेस डेटा लेयर से संबंधित है, जबकि संग्रहीत कार्यविधियाँ तर्क हैं।

मुझे लगता है कि संग्रहीत प्रक्रियाओं के बिना दुनिया बहुत गंभीर जगह होगी।

क्या वे वास्तव में त्रि-स्तरीय अलगाव का उल्लंघन करते हैं?


9
बस उनसे पूछें कि क्या उन्होंने 3 1/2 टियर आर्किटेक्चर के बारे में नहीं सुना है ...
dreza

7
याद रखें कि स्तरों और परतें एक और समान नहीं हैं।
नं।

2
@ emmad-kareem इस प्रश्न ने मेरी मदद की ( stackoverflow.com/questions/120438/… )। समस्या स्पैनिश है (मेरी मातृभाषा) भाषा तकनीकी साहित्य इसके लिए एक शब्द का उपयोग करता है ("केप"), जबकि अंग्रेजी में दो अलग-अलग शब्द हैं।
ट्यूलेंस कोरडोवा

1
@ user1598390, आप सही हैं कि यह विशेष रूप से भ्रमित कर सकता है कि सॉफ्टवेयर की दुनिया को पर्याप्त कठोरता नहीं मिली है जब यह एक भाषा में परिभाषाओं की बात आती है तो भाषाओं में अकेले जाने दें।
NoChance

1
3-टियर आर्किटेक्चर एक तार्किक अवधारणा है, न कि भौतिक अवधारणा। आप संग्रहीत प्रक्रियाओं का उपयोग करके व्यावसायिक नियमों को लागू कर सकते हैं, और भौतिक रूप से डेटाबेस में रहते हुए, उन संग्रहीत कार्यविधियाँ अभी भी व्यावसायिक तर्क स्तरीय का हिस्सा हैं।
क्रेग

जवाबों:


33

आपके सहयोगी कार्यान्वयन के साथ वास्तुकला का सामना कर रहे हैं।

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

आइए एक तीन-स्तरीय एप्लिकेशन को देखें, जहां दो स्तरों को डेटाबेस पर लागू किया गया है:

  • डाटा टीयर: चार मानक तालिका के संचालन का उपयोग करके एक्सेस डेटाबेस तालिकाओं होते हैं ( INSERT, UPDATE, DELETEऔर SELECT)।
  • लॉजिक टियर: संग्रहीत कार्यविधियों से मिलकर जो केवल व्यावसायिक तर्क को लागू करते हैं और केवल ऊपर उल्लिखित विधियों का उपयोग करके डेटा टियर का उपयोग करते हैं।
  • प्रेजेंटेशन टियर: एक वेब सर्वर रनिंग कोड से युक्त होता है, जो केवल स्टोर किए गए प्रोसीजर कॉल करके लॉजिक टियर को एक्सेस करता है।

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

इस तरह की बात और नहीं है या नहीं, यह एक निश्चित स्थिति में स्वीकार्य है और आपके सहयोगियों को आपके निर्णय का उपयोग करना है।


2
इसलिए मैं उन्हें बता सकता हूं कि संग्रहीत प्रक्रियाएं तर्कपूर्ण स्तरीय, वास्तुकला-वार का हिस्सा हैं, इस तथ्य की परवाह किए बिना कि वे डेटाबेस में संग्रहीत हैं?
ट्यूलेंस कोरडोवा

3
@ user1598390: हाँ। हालांकि इसे 3-लेयर कहने के लिए लेयर होगा, और 3 टियर में नहीं।
जोर्मेनो

4
@ user1598390: आप कह सकते हैं कि जब तक आप इसे साबित कर सकते हैं। पहली बार प्रस्तुति परत SELECTसीधे तालिकाओं (डेटा टियर) से होती है, मॉडल को तोड़ दिया गया है।
ब्लरफ्ल

@blrfl कुछ ऐसा है जिस पर मैंने ध्यान दिया है;)
ट्यूलेंस कोरडोवा

2
@ user1598390: यह ठीक है, बस याद रखें कि लक्ष्य अलग-अलग हार्डवेयर पर चीजों को न डालकर चिंताओं का तार्किक विभाजन है।
jmoreno

19

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

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


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

1
तथास्तु। लोगों को लगता है कि sprocs = व्यापार "कोड" लगता है। उन्हें डीबी 'एपीआई' के रूप में सोचा जाना चाहिए, और फिर वे बहुत अधिक समझ में आते हैं। बेशक, वे किनारे के मामलों को भी ठीक कर सकते हैं जहां आपको अपने तर्क से प्रदर्शन की आवश्यकता होती है!
gbjbaanb

5

2004 से एटवुड की सलाह आज भी सही है, केवल अब हमें ओआरएम का लाभ है।

http://blog.codinghorror.com/who-needs-stored-procedures-anyways/

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


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

3

संक्षिप्त सारांश: यह वास्तव में संग्रहीत प्रक्रियाओं और व्यावसायिक आवश्यकताओं के आपके उपयोग पर निर्भर करता है।

ऐसी कई परियोजनाएँ हैं जो एक त्रि-स्तरीय वास्तुकला का उपयोग करती हैं और व्यावसायिक आवश्यकताओं की प्रकृति के आधार पर कुछ ऑपरेशनों को डेटा स्तर पर स्थानांतरित करने की आवश्यकता हो सकती है

शब्दावली के बारे में बोलते हुए, सामान्य शब्दों में इन स्तरों का वर्णन किया गया है:

  • प्रस्तुति स्तरीय , या उपयोगकर्ता सेवाओं की परत - एक उपयोगकर्ता को एप्लिकेशन तक पहुंच प्रदान करती है।
  • मध्य स्तरीय , या व्यावसायिक सेवाओं की परत - व्यवसाय और डेटा नियमों के होते हैं।
  • डेटा स्तरीय या डेटा सेवाओं की परत - एक डेटाबेस या स्थायी भंडारण में आमतौर पर संग्रहीत निरंतर डेटा के साथ इंटरैक्ट करती है।

आमतौर पर दी गई वास्तुकला के लिए, मध्य स्तरीय या व्यावसायिक सेवाओं की परत, व्यवसाय और डेटा नियमों के होते हैं। हालाँकि, कभी-कभी भारी टेरर ऑपरेशंस और / या डेटा नियमों को शिफ्ट करने के लिए डेटा टियर - स्टोर की गई प्रक्रियाओं के सेट के माध्यम से बदलाव करना बड़ा अंतर बनाता है ।

त्रिस्तरीय डिजाइन के लाभ हैं:

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

इस प्रकार, यह वास्तव में एक केस-बेस अप्रोच है जो अपने आप में ट्रेड-ऑफ है। हालाँकि, थ्री-टियर आर्किटेक्चर मॉडल के Microsoft डिज़ाइन दिशानिर्देश आपके व्यवसाय तर्क को मध्य-स्तरीय रखने की सलाह देते हैं ।


2

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

एक परत उन तत्वों के लिए एक तार्किक संरचना तंत्र है जो आपके सॉफ़्टवेयर समाधान को बनाते हैं; एक टियर सिस्टम इंफ्रास्ट्रक्चर के लिए एक शारीरिक संरचना तंत्र है। ( संदर्भ )

मेरी राय में डेटाबेस में व्यावसायिक तर्क के निर्माण के साथ दो प्रमुख समस्याएं हैं:

  1. कोड और लाइब्रेरी: आप पाएंगे कि प्रोग्रामर सीक्यू, पीएल / एसक्यूएल, टीएसक्यूएल आदि में सी #, जावा आदि की तुलना में प्रोग्राम करने में सक्षम हैं। प्रोग्रामिंग लैंग्वेज में शानदार आईडीई, शानदार लाइब्रेरी और फ्रेमवर्क का भी फायदा है।

  2. क्षैतिज स्केलेबिलिटी: जिस तरह से आप अपने सिस्टम को स्केल कर सकते हैं उसका एकमात्र तरीका भौतिक सर्वर को बदलना है, जिस पर डेटाबेस अधिक शक्तिशाली है, जो महंगा है (64 जीबी रैम वाला सर्वर); संबंधपरक डेटाबेस क्षैतिज रूप से बहुत खराब हैं, और यहां तक ​​कि अधिक खर्चों पर भी। हालांकि, OO- निर्मित सर्वर में व्यावसायिक तर्क के साथ आप कई नोड्स पर सर्वर लगाकर क्षैतिज रूप से बहुत अच्छी तरह से स्केल कर सकते हैं (जावा में कई एप्लिकेशन सर्वर इस का समर्थन करते हैं)।


-1

हमने कुछ समय पहले अपने कार्यालय में यह बहस की थी, मैं डेटाबेस डेवलपमेंट का पक्ष ले रहा था, इस पर मेरे विचार हैं

  1. यदि आप ओरेकल डेटाबेस का उपयोग कर रहे हैं, तो आपको पीएल / एसक्यूएल का यथासंभव उपयोग करना चाहिए, क्योंकि यकीन है कि जो कंपनियां निवेश करती हैं, वे अब से कम से कम 10 साल के लिए ओरेकल से चिपके रहेंगे। कल के अनुप्रयोगों में आप Oracle फॉर्म, आज .net वेब फॉर्म का उपयोग कर रहे थे, फिर MVC, फिर कल आप angularjs का उपयोग करेंगे और बस restfull एप की आवश्यकता होगी। यदि आप अधिकतम तर्क डेटाबेस में हैं, तो आप आसानी से नई फ्रंट एंड टेक्नोलॉजी पर माइग्रेट कर सकते हैं।
  2. डेटाबेस विकास बहुत तेज़ और बहुत कुशल प्रदर्शन बुद्धिमान है। बस आपको एक संभावना देने के लिए। हमारी परियोजना में 7 एप्लिकेशन डेवलपर और एक डेटाबेस डेवलपर थे, और 80% तर्क डेटाबेस में थे।
  3. यदि आप ओरेकल का उपयोग कर रहे हैं तो आप उपयोगिताओं का उपयोग करके सीधे अपने डेटाबेस प्रक्रियाओं को Res फुल आपी में बदल सकते हैं।

एप्लिकेशन डेवलपर्स को सबसे मजबूत तर्क यह देता है कि व्यावसायिक तर्क डेटाबेस से स्वतंत्र होना चाहिए ताकि आप आसानी से डेटाबेस को बदल सकें। मुझे लगता है कि अगर कोई कंपनी ओरेकल का उपयोग कर रही है तो वे अन्य तकनीक पर क्यों स्विच करेंगे, इसके बजाय एप्लिकेशन लॉजिक अप्रचलित होने की संभावना अधिक है। मुद्दा ज्यादातर डेटाबेस संसाधन की नई प्रतिभाओं की कमी है, ज्यादातर लोग सरल वेबसाइटों को शुरू करेंगे जहां वे mysql या sqlserver का उपयोग कर रहे हैं। ये लोग तब वरिष्ठ लीडर बन जाते हैं और एप्लिकेशन लेयर के साथ भावनात्मक लगाव रखते हैं :) वे यहां तक ​​कि समझना या बहस नहीं करना चाहते हैं।


"यदि आप ओरेकल डेटाबेस का उपयोग कर रहे हैं, तो आपको पीएल / एसक्यूएल का यथासंभव उपयोग करना चाहिए," संग्रहीत प्रक्रियाएं लोड करती हैं जो आमतौर पर एक आर्किटेक्चर में स्केल-स्केल सिस्टम के लिए सबसे अधिक बोतल-गर्दन और कठोर होती हैं। वे एक संस्करण नियंत्रण और इकाई-परीक्षण के दृष्टिकोण से प्रबंधन करने के लिए एक दर्द भी हैं "क्योंकि यकीन है कि जो कंपनियां निवेश करती हैं, वे अब से कम से कम 10 साल तक ओरेकल से चिपके रहेंगे।" यह सिर्फ बकवास है। आप ऐसा क्यों सोचते हैं? यदि आप अपने सिस्टम को बेवकूफ PL / SQL प्रक्रियात्मक कचरे से भरते हैं, तो आप किसी कंपनी को किसी समकालीन चीज़ में जाने से रोक सकते हैं। यह सच हो सकता है।
जिमीजैम
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.