डेटाबेस को कितना व्यावसायिक तर्क लागू करना चाहिए?

107

मैंने कुछ परियोजनाओं में काम किया है, जहां अधिकांश व्यापारिक तर्क डेटाबेस पर (ज्यादातर संग्रहीत प्रक्रियाओं के माध्यम से) लागू किए गए थे। दूसरी तरफ, मैंने कुछ साथी प्रोग्रामरों से सुना है कि यह एक बुरा अभ्यास है ("डेटा स्टोर करने के लिए डेटाबेस हैं। बाकी काम करने के लिए अनुप्रयोग हैं")।

इनमें से कौन सा दृष्टिकोण आम तौर पर बेहतर है?

DB में व्यावसायिक तर्क को लागू करने के बारे में मैं सोच सकता हूं:

व्यावसायिक तर्क का केंद्रीकरण;
आवेदन प्रकार, प्रोग्रामिंग भाषा, ओएस, आदि की स्वतंत्रता;
डेटाबेस प्रौद्योगिकी के प्रवासन या बड़े रिफैक्टोरिंग (AFAIK) के लिए कम प्रवण होते हैं;
अनुप्रयोग प्रौद्योगिकी प्रवास (जैसे: .NET से जावा, पायल टू पायथन, आदि) पर कोई पुन: कार्य नहीं।

विपक्ष:

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

नोट: मैं जिन डेटाबेस के बारे में बात कर रहा हूं वे SQL सर्वर, Oracle, MySql आदि जैसे रिलेशनल, लोकप्रिय डेटाबेस हैं।

धन्यवाद!

— राफेल
स्रोत

3

आपको इस प्रश्न का उत्तर उपयोगी लग सकता है।

— ब्लरफ्ल

7

यह तर्क पहले से ही किया गया है विस्तृत रूप से बहस । हम यहाँ बातचीत में और क्या सार्थक जोड़ सकते हैं?

— रॉबर्ट हार्वे

2

@gnat: पास भी नहीं।

— रॉबर्ट हार्वे

1

प्रोग्रामर.स्टैकएक्सचेंज.

— com

7

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

— क्रेग

82

व्यावसायिक तर्क डेटाबेस में नहीं जाता है

यदि हम मल्टी-टियर एप्लिकेशनों के बारे में बात कर रहे हैं, तो यह बहुत स्पष्ट है कि व्यावसायिक तर्क, एक विशेष उद्यम चलाने वाली बुद्धि, व्यापार तर्क परत में है, डेटा एक्सेस लेयर में नहीं।

डेटाबेस कुछ चीजें वास्तव में अच्छी तरह से करते हैं:

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

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

और निश्चित रूप से, ऐसी चीजें हो सकती हैं जो प्रदर्शन और अन्य कारणों के लिए डेटाबेस में की जाती हैं:

एक लेखा अवधि बंद करना
हिसाब लगाना
रात्रिकालीन बैच प्रक्रियाएं
असफल ओवर

स्वाभाविक रूप से, पत्थर में कुछ भी नहीं उकेरा गया है। संग्रहीत कार्यविधियाँ कार्यों की एक विस्तृत सरणी के लिए उपयुक्त हैं, क्योंकि वे डेटाबेस सर्वर पर रहते हैं और कुछ निश्चित ताकत और फायदे हैं।

हर जगह संग्रहीत प्रक्रिया

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

लेकिन आप क्या जोखिम उठाते हैं?

विक्रेता बंदी
विशेष कौशल सेट के साथ डेवलपर्स की आवश्यकता
संयमी प्रोग्रामिंग उपकरण, कुल मिलाकर
बहुत तंग सॉफ्टवेयर युग्मन
चिंताओं की जुदाई नहीं

और हां, अगर आपको एक वेब सेवा की आवश्यकता है (जो कि शायद यह सब जहां बढ़ रहा है, वैसे भी), तो आपको अभी भी इसका निर्माण करना होगा।

तो ठेठ अभ्यास क्या है?

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

यह कितनी अच्छी तरह काम करता है? बहुत अच्छी तरह से, और संग्रहीत प्रक्रियाओं और विचारों को लिखने की तुलना में बहुत अधिक तेजी से। यह आमतौर पर आपके डेटा एक्सेस आवश्यकताओं के लगभग 80% को कवर करता है, ज्यादातर CRUD। अन्य 20% क्या शामिल है? आपने यह अनुमान लगाया: संग्रहीत प्रक्रियाएं, जो सभी प्रमुख ORM सीधे समर्थन करती हैं।

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

— रॉबर्ट हार्वे
स्रोत

3

आपके शानदार जवाब के लिए धन्यवाद, @Robert हार्वे। लेकिन मैं "वेंडर लॉक-इन" तर्क के बारे में सोच रहा था: किसी एप्लिकेशन को भी वेंडर लॉक-इन बनाने के लिए किसी विशेष तकनीक (जैसे, .NET या जावा स्टैक) का उपयोग नहीं कर रहा था? या फिर ऐप-ओरिएंटेड स्टैक विक्रेता लॉक-इन बनाम डीबी एक के फायदे हैं?

— राफेल 12

3

@RobertHarvey, लेकिन .NET में मौजूद एप्लिकेशन लॉजिक का हिस्सा अभी भी .NET में बंद है। वही PHP और जावा के लिए जाता है।

— पचेरियर

2

@ स्पेसर: विक्रेता-लॉकिन द्वारा, मैं डेटाबेस विक्रेता की बात कर रहा हूँ। वास्तविक अभ्यास में, डेटाबेस (और प्रोग्रामिंग स्टैक) को शायद ही कभी बदल दिया जाता है।

— रॉबर्ट हार्वे

2

@kai: ठीक है, आप इसे दोनों तरीकों से नहीं कर सकते। या तो आप स्टब्स और मॉक का उपयोग करते हैं और इस तथ्य के साथ रहते हैं कि परीक्षण कृत्रिम है, या आप एक परीक्षण लिखते हैं जो यथार्थवादी है, और थोड़ी देरी के साथ रहते हैं। मुझे संदेह है कि आपका ट्रेडऑफ़ 10 मिनट बनाम 30 सेकंड है।

— रॉबर्ट हार्वे

3

हो सकता है कि देर से लेकिन मैं इस बात पर विचार कर रहा हूं कि व्यावसायिक तर्क को लागू करने वाली संग्रहीत कार्यविधियाँ व्यावसायिक तर्क परत से संबंधित हैं, न कि डेटा स्तर पर। वे ORM की कोई आवश्यकता नहीं के साथ अलग प्रकार के हैं।

— पैरालिफ़

16

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

मैं आपके पक्ष और विपक्ष का विवाद करता हूं।

आप दावा करते हैं कि यह आपके व्यावसायिक तर्क को केंद्रीकृत करता है। इसके विपरीत, मुझे लगता है कि यह इसे विकेंद्रीकृत करता है। एक उत्पाद जिसमें मैं वर्तमान में काम करता हूं, हम अपने बहुत से व्यावसायिक तर्क के लिए संग्रहीत प्रक्रिया का उपयोग करते हैं। हमारे कई प्रदर्शन मुद्दे कॉलिंग फ़ंक्शन से बार-बार आते हैं। उदाहरण के लिए

select <whatever>
from group g
where fn_invoker_has_access_to_group(g.group_id)

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

उपरोक्त समस्या का एक सामान्य समाधान फ़ंक्शन से तर्क को निकालना और इसे क्वेरी में विलय करना है। अब आपने एनकैप्सुलेशन और डुप्लिकेट लॉजिक को तोड़ दिया है।

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

declare some_cursor
while some_cursor has rows
    exec some_other_proc
end

यदि आप नेस्टेड आउट से कोड खींचते हैं, तो आप फिर से विकेंद्रीकरण करते हैं। इसलिए, आप एन्कैप्सुलेशन और प्रदर्शन के बीच चयन करने के लिए मजबूर हैं।

सामान्य तौर पर, मुझे लगता है कि डेटाबेस खराब हैं:

गणना
Iteration (वे सेट संचालन के लिए अनुकूलित हैं)
भार संतुलन
पदच्छेद

डेटाबेस अच्छे हैं:

ताला लगाना और खोलना
डेटा और उनके रिश्तों को बनाए रखना
अखंडता सुनिश्चित करना

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

हालाँकि, आप सही हैं, कि यह आपके एप्लिकेशन की प्रोग्रामिंग भाषा से आपके व्यवसाय के तर्क को कम कर देता है, लेकिन मैं यह नहीं देखता कि यह एक फायदा क्यों है। अगर आपके पास जावा ऐप है, तो आपके पास जावा ऐप है। जावा कोड के एक समूह को संग्रहीत प्रक्रियाओं में परिवर्तित करने से इस तथ्य को नहीं बदला जाता है कि आपके पास जावा ऐप है।

मेरी प्राथमिकता डेटाबेस कोड को दृढ़ता पर केंद्रित रखने की है। आप एक नया विजेट कैसे बना सकते हैं? आपको 3 तालिकाओं में सम्मिलित होना चाहिए और वे एक लेनदेन में होनी चाहिए। वह एक संग्रहित प्रक्रिया में है।

एक विजेट के लिए क्या किया जा सकता है परिभाषित करना और विजेट खोजने के लिए व्यावसायिक नियम आपके आवेदन में हैं।

— ब्रैंडन
स्रोत

8

SQL सर्वर में केवल खराब लिखित sp को लूप में बुलाया जाना चाहिए, आप इसे एक पैरामीटर में डेटा के सेट भेज सकते हैं और एक सेट-आधारित प्रक्रिया कर सकते हैं।

— HLGEM

2

जब भी WHERE क्लॉज में UDF होता है, तो SQL सर्वर एक उप-इष्टतम क्वेरी प्लान उत्पन्न करेगा।

— जिम जी।

7

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

— सम यि

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

— ब्रैंडन

1

यह उदाहरण डीबी में बिज़ लॉजिक के मुख्य भागों को रखने के लिए एक तर्क है: प्लेग की तरह चलने के दृष्टिकोण (सेट-आधारित अभिव्यक्तियों के बजाय कोड या कर्सर छोरों) से बचने के लिए। प्रोग्रामर वस्तुओं के सेट को एक पुनरावृत्त तरीके (लूप, ट्रैवर्स) के रूप में मानते हैं, जो संभावित रूप से अनावश्यक भार या कई एकल क्वेरी राउंडट्रिप्स के चयन N + 1 समस्या की ओर जाता है। SQL या भाषा आधारित अभिव्यक्तियों (जैसे LINQ) का उपयोग करके, उन्हें जब भी संभव हो, सेट आधारित दृष्टिकोण का उपयोग करने के लिए मजबूर किया जाएगा।

— एरिक हार्ट

10

मैंने 2 अलग-अलग कंपनियों में काम किया है जिनकी विषय पर अलग-अलग दृष्टि थी।

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

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

इसलिए जब जरूरत हो तब सावधानी के साथ स्टोर की हुई प्रक्रिया का उपयोग करें।

— जीन-फ्रांकोइस कोटे
स्रोत

3

संग्रहीत प्रक्रिया इकाई परीक्षण योग्य हैं। कुछ तकनीकों के लिए यहां देखें ।

— रॉबर्ट हार्वे

4

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

— जीन-फ्रांकोइस कोटे

1

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

— जीन-फ्रांस्वा कोटे

1

यदि आप db और आवश्यक ऑब्जेक्ट बनाते हैं, तो sp, test, और फिर बाद में इसे फाड़ देते हैं, यह एक यूनिट टेस्ट है। यह काम की एक इकाई का परीक्षण करता है।

— टोनी हॉपकिंसन

2

संग्रहीत कार्यविधियों के साथ प्रदर्शन का लाभ नहीं उठाया गया है?

— जेएफओ

9

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

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

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

— डैन पिचेलमैन
स्रोत

2

डेटाबेस को "ओवरप्राइज्ड" की / वैल्यू स्टोर के रूप में उपयोग करना एक पूरी तरह से मान्य तकनीक है, क्योंकि NoSQL चिकित्सकों की किंवदंतियों को प्रमाणित करेगा।

— रॉबर्ट हार्वे

1

@RobertHarvey आप स्पष्ट रूप से सही हैं, लेकिन किसी भी तरह मेरी आंत इस बात पर जोर देती है कि डेटाबेस से एक सरल / सस्ता / तेज समाधान होना चाहिए अगर आपको सभी की जरूरत है एक कुंजी / मूल्य की दुकान। मुझे NoSQL के बारे में अधिक जानने की आवश्यकता है।

— डेन पिकेलमैन

2

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

— जेएफओ

2

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

— राफेल

@ राफेल या आप

— डेमी

9

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

http://en.wikipedia.org/wiki/Set_operations_(SQL)

यदि व्यावसायिक तर्क में कुछ प्रकार की गणना शामिल है, तो यह संभवतः डेटाबेस / स्टोर प्रक्रिया से बाहर है क्योंकि डेटाबेस वास्तव में लूपिंग और गणना के लिए डिज़ाइन नहीं किए गए हैं।

हालांकि ये कठिन और तेज़ नियम नहीं हैं, लेकिन यह एक अच्छा शुरुआती बिंदु है।

— जॉन रेन्नोर
स्रोत

6

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

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

— HLGEM
स्रोत

3

कुछ वर्षों के बाद, यह सवाल अभी भी महत्वपूर्ण है ...

मेरे लिए सरल नियम-ऑफ-थंब: यदि यह एक तार्किक बाधा या सर्वव्यापक अभिव्यक्ति (एकल कथन) है, तो इसे डेटाबेस में रखें (हाँ, विदेशी कुंजी और चेक की कमी व्यावसायिक तर्क है, भी!)। यदि यह प्रक्रियात्मक है, जिसमें लूप और सशर्त शाखाएं शामिल हैं (और वास्तव में इसे एक अभिव्यक्ति में नहीं बदला जा सकता है), इसे कोड में रखें।

कचरा डंप DBs से बचें

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

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

प्रक्रियात्मक कोड के बजाय अभिव्यक्तियाँ (सेट-आधारित)

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

DB डेटा अखंडता तंत्र का उपयोग करें

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

संग्रहित प्रक्रियाएं?

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

जबकि ORM जनरेट किया गया, SQL सहित एप्लिकेशन पक्ष, डेटाबेस के अंदर नहीं है, संग्रहीत प्रक्रियाओं के विपरीत, मैं अभी भी इसे डेटाबेस कोड के रूप में गिनता हूं। क्योंकि इसके लिए अभी भी एसक्यूएल और डेटाबेस ज्ञान (सबसे सरल सीआरयूडी को छोड़कर) की आवश्यकता होती है, और, यदि ठीक से लागू किया जाता है, तो आमतौर पर सी # या जावा जैसी प्रोग्रामिंग भाषाओं के साथ बनाई गई प्रक्रियात्मक कोड की तुलना में बहुत भिन्न होता है।

— एरिक हार्ट
स्रोत

2

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

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

एक आधुनिक समय एप्लिकेशन डेवलपर के पास दूसरे मॉडल के साथ अधिक आत्मीयता होगी। यदि आप एक बड़े क्लाइंट-सर्वर सिस्टम के साथ बड़े हुए हैं, तो आप संभवतः दूसरे शिविर में होंगे।

यहां अक्सर कई गैर-तकनीकी पर्यावरण संबंधी कारक शामिल होते हैं, इस सवाल का कोई सामान्य जवाब नहीं है।

— मार्टिन मात
स्रोत

2

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

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

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

— CyberFonic
स्रोत

अच्छा उदाहरण और स्पष्टीकरण।