डेटाबेस लेयर में एप्लिकेशन लॉजिक लगाने के खिलाफ या तर्क क्या हैं? [बन्द है]


45

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

व्यक्तिगत रूप से मैं डिबग को आसान बनाने और परतों की जिम्मेदारियों को अलग रखने के लिए आवेदन परत में यथासंभव रखना पसंद करूंगा।

इस पर आपके विचार क्या हैं, और डेटाबेस लेयर में लागू करने के लिए क्या होना चाहिए या नहीं होना चाहिए?

संपादित करें यह प्रश्न भी डीबीए के दृष्टिकोण से dba.se पर कवर किया गया है। जैसा कि प्रोग्रामर.से और dba.se के पास अलग-अलग दर्शक और पूर्वाग्रह हैं, भविष्य के पाठक उनके लिए सबसे अच्छा काम करने से पहले जवाब के दोनों सेटों की समीक्षा करना चाहते हैं।


13
मुझे भी दिलचस्पी होगी अगर डेटाबेस लेयर में ऐप लॉजिक डालने के किसी भी प्रस्तावक को यूनिट लॉजिक के ऐप लॉजिक के तरीके मुहैया कराए जा सकें।
क्रिस बकेट

@ क्रिस: ओरेकल के लिए plunit.com/index.htm है
टोनी एंड्रयूज

10
व्यावसायिक तर्क कृपया, तर्क तर्क नहीं - उद्देश्य समस्या डोमेन होना चाहिए, न कि तकनीक विकल्प!
फिल लेलो

1
@ क्रिस: मुझे यकीन है कि वे कर सकते हैं - डेटा के साथ तालिकाओं को आबाद करें (आपको ऐप परत में नकली कक्षाएं बनाना होगा), फिर एक स्क्रिप्ट के साथ एसपी को स्वचालित रूप से कॉल करें। पूरी बात को एसक्यूएल स्टेटमेंट की एक स्क्रिप्ट के रूप में लिखा जा सकता है, सफाई और इसे स्थापित करते समय। यहाँ 3 यूनिट टेस्ट एसक्यूएल टूल्स के लिए एक लिंक दिया गया है: toadworld.com/BLOGS/tabid/67/EntryId/67/…
gbjbaanb

मैंने हाल ही में अपने ब्लॉग पर इस पर अपने विचार लिखे
गयूस

जवाबों:


38

मेरे सिर के ऊपर से, एप्लीकेशन लेयर में लॉजिक लगाने के फायदे

  1. परीक्षण करने की क्षमता । यह वास्तव में खुद पर एक अच्छा पर्याप्त कारण होना चाहिए।
  2. बेहतर कोड संरचना । SQL के साथ उचित OO- आर्किटेक्चर का पालन करना बहुत मुश्किल है। यह आमतौर पर कोड को बनाए रखना आसान बनाता है।
  3. कोड करने के लिए आसान । जिस भी भाषा में आप इसका उपयोग कर रहे हैं, वह सभी अलग-अलग भाषा सुविधाओं के कारण आमतौर पर एप्लिकेशन परत में कोड करना आसान है।
  4. कोड पुन: उपयोग । डेटाबेस में कोड साझा करने की तुलना में पुस्तकालयों के साथ कोड साझा करना बहुत आसान है।

5
क्या हम स्रोत को नियंत्रित करने की क्षमता को भी जोड़ सकते हैं ताकि वे संशोधित हो सकें? शायद यह सिर्फ मेरी निजी पकड़ है ... (हाँ, मैं स्पष्ट रूप से उन तरीकों को छोड़ रहा हूं जो इसे किया जा सकता है ...)
jcolebrand

6
पुन: 4. महान! आइए मेरे सोलारिस जावा ऐप में उस वीबी लॉजिक का इस्तेमाल करें ... ओह, हैंग ऑन ...
फिल लेलो

11
फिल, महान! चलो मेरे एसक्यूएल सर्वर अनुप्रयोग में अपने ओरेकल तर्क का उपयोग करें ... ओह, रुको ...
क्रेग

9
@ क्रेग वास्तविकता यह है कि संगठन डेटाबेस विक्रेताओं को अनुप्रयोगों या भाषाओं को बदलने की तुलना में बहुत कम बार बदलते हैं। हालाँकि, मेरी बात और थी कि यह ऐप बनाम डीबी का लाभ नहीं है, न कि डीबी यहां बेहतर है; वहाँ है समर्थक और चोर के दृष्टिकोण या तो
फिल लेलो

1
@jcolebrand - ठीक है, यदि आप डेटाबेस विकास कर रहे हैं , तो VS 2010 बम है। मैं अपने समूह को SSMS से VS में विकास कार्य के लिए परिवर्तित कर रहा हूं और इस TDD चीज को अपनाना चाहता हूं, जो देवों के साथ क्रोध है। यह महत्वपूर्ण डेटाबेस विकास कार्य के साथ किसी भी दुकान के लिए समय का एक सार्थक निवेश है (और निश्चित रूप से SQL सर्वर की ओर झुकता है)।
निक चामास 21

11

हालांकि संग्रहित प्रक्रियाओं के साथ संस्करण नियंत्रण का उपयोग करना संभव है (उदाहरण के लिए Redgate डेटाबेस टूल TFS के साथ एकीकृत), यह हमेशा उतना सीधा नहीं होता जितना कि यह एप्लिकेशन कोड के साथ होता है।

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


4
"नहीं के रूप में सीधे आगे के रूप में यह आवेदन कोड के साथ है" क्यों नहीं?
निमचम्पस्की

@Nim - जब तक मैं गलत नहीं कर रहा हूँ, इसमें डेटाबेस प्रोजेक्ट्स शामिल हैं बजाय सरल "इसे संपादित करें और यह जांचे" कि जब स्रोत नियंत्रण को आपके IDE में एकीकृत किया जाता है तो आपको मिलता है।
ChrisF

1
मुझे लगता है कि आप अपने डेटाबेस में बदलाव को बिना संस्करण नियंत्रण के कर सकते हैं, लेकिन आप वास्तव में कोड के साथ ऐसा नहीं कर सकते ...
जैको प्रिटोरियस

5
@Jaco नहीं, लेकिन आप SCM में इसे डाले बिना / रिलीज़ कोड चला सकते हैं। मैला रिलीज प्रबंधन प्रबंधन टेढ़ा रिलीज प्रबंधन है जो भी तकनीक आप उपयोग करते हैं।
फिल लेलो

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

8

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


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

1
मेरा अनुमान है कि ऐसा इसलिए है क्योंकि वे ज्यादातर समय कुछ भी नहीं करने के लिए बैठते हैं, इसलिए जब आप अंत में उन्हें समीक्षा के लिए कुछ देते हैं कि वे वास्तव में ध्यान आकर्षित करना चाहते हैं। हो सकता है कि यह सिर्फ मैं ही हो ...
जैको प्रीटोरियस

5
@ जेफ़ ओ डिज़ाइन में डीबीए क्यों शामिल नहीं था? डीबीए अन्य डेवलपर्स की तुलना में डेटाबेस अनुकूलन के बारे में बहुत अधिक जानते हैं, और उन्हें टीम के हिस्से के रूप में माना जाना चाहिए।
फिल लेलो

8
@ पील लेलो: क्योंकि अधिकांश सॉफ्टवेयर डेवलपर्स अभिमानी cusses हैं जो सोचते हैं कि वे यह सब स्वयं सीख सकते हैं। यही कारण है कि इतने सारे डेटाबेस ऐसे कबाड़ के ढेर हैं।
बस मेरा सही विकल्प

2
लगता है जैसे आपके डीबीए ने आपको सुरक्षित रखने के लिए खदान के चारों ओर एक बाड़ बनाया है। धन्यवाद बनो!
जेम्स एंडरसन

7

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


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


इस। आप चाहते हैं कि आपका डेटाबेस लचीला हो। इसलिए आपके डेटा से जुड़े तर्क वहां पर रहने चाहिए।
अरख

6

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

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

एंटरप्राइज़ एप्लिकेशन भी ऐसे होते हैं जो डेटाबेस से कई स्थानों से इनपुट होते हैं और केवल समानता होती है। जिस सिस्टम में मैं काम करता हूं, उसमें सैकड़ों अलग-अलग एप्लिकेशन हैं और साथ ही क्लाइंट डेटा के सैकड़ों इंपोर्ट, क्लाइंट्स को डेटा एक्सपोर्ट करने और वेयरहाउस को डेटा देने और मल्टिपल रिपोर्टिंग सिस्टम का इस्तेमाल करते हैं। एक रिकॉर्ड जोड़ते समय जो कोड अच्छी तरह से काम करता है वह विफल होता है जब मुझे 20,000,000 आयात करना पड़ता है। हमें एक बार एप्लिकेशन लेयर का उपयोग करने के लिए मजबूर होना पड़ा, क्योंकि यह वह जगह थी जहां तर्क था और 18 घंटे बाद प्रक्रिया को अधूरा रोकना पड़ा। तालिका में सभी डेटा रिकॉर्ड पर लागू होने वाला तर्क डेटाबेस में होना चाहिए जब आपके पास एक डेटा परत नहीं हो सकती है जिसका उपयोग हर कोई करता है।

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


4
यह सबसे अच्छा जवाब है। यदि व्यावसायिक तर्क अनुप्रयोग में है, तो यदि विभिन्न तर्क का उपयोग करने वाले कई अनुप्रयोग हैं, तो डेटाबेस वास्तव में खराब स्थिति में समाप्त हो सकता है।
सैम

5

दीर्घाकार। नीचे सारांश देखें।

आरडीबीएमएस

RDBMS का संबंध रिलेशनल डेटाबेस मैनेजमेंट सिस्टम से है। यह एक रिलेशनल डेटा बेस को प्रबंधित करने के लिए एक सिस्टम है। डेटा वहाँ संग्रहीत है। आँकड़े। इसे व्यावसायिक तर्क नहीं कहते हैं।

व्यापार प्रक्रिया

व्यावसायिक तर्क का क्या मतलब है, वास्तव में? मेरे लिए, यह तार्किक रूप से व्यावसायिक प्रक्रियाओं का वर्णन है।

प्रक्रियाएं वे व्यावसायिक गतिविधियां हैं जो नियमित रूप से होती हैं, पर्याप्त है कि वे अब तदर्थ नहीं हैं। ये हर व्यवसाय के लिए अलग हैं।

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

व्यापार

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

त्वरित चक्कर: आपको 2 दिनों में 40 मिलियन rivets की आवश्यकता होती है, आप इंटरनेट पर कुछ लोगों से एक पेपैल खाते के साथ ऑर्डर नहीं करने जा रहे हैं, चाहे वह कितना भी सस्ता हो, आपकी कीमत आपके सामान्य विक्रेता की तुलना में अधिक है।

प्रक्रिया ज्ञान

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

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

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

अनुप्रयोग तर्क

मैंने कहा नही। मैं कहता हूं कि आवेदन तर्क आवेदन के अंदर रहता है। डेटा बहुत सामान्य तरीके से डेटाबेस में जाता है, और फिर रिपोर्टिंग और ड्रिलिंग और रोलअपिंग और पिविंग और क्यूबिंग के लिए डेटॉलहाउस को ETL'd मिलता है।

डेटा

मैं यह भी कहता हूं कि डेटा अनुप्रयोग को रेखांकित करता है, इसलिए डेटा सामान्यीकरण प्रयास एप्लिकेशन विशिष्ट नहीं होना चाहिए, और व्यवसाय-विशिष्ट भी नहीं होना चाहिए, बल्कि व्यापार-सामान्य होना चाहिए। क्या आप राज्य कोड स्टोर करते हैं? आपको INCITS 38: 2009 (http://www.census.gov/geo/www/ansi/statetables.html) का उपयोग करना चाहिए क्योंकि यह व्यवसायों में पोर्टेबल है। इससे कई अनुप्रयोगों के लिए डेटा में हेरफेर करना आसान हो जाता है।

NoSQL?

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

वास्तविक कोड

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

डेटाबेस में गिरावट

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

सारांश

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

चेतावनी

मैंने अपना हिस्सा dba-ing किया है और मैंने dba.se पर उत्तर पढ़े हैं, लेकिन सभी ईमानदारी से वे जो बात कर रहे हैं वह डेटा-अखंडता के मुद्दे और प्रदर्शन के मुद्दे हैं। मैं इस बात से पूरी तरह सहमत हूं कि कॉरपोरेट डेटा को छूने वाले लोगों को पता होना चाहिए कि वे क्या कर रहे हैं, चाहे डीबीए या प्रोग्रामर या एसएएस के वरिष्ठ विश्लेषक पढ़ें / लिखें पहुंच के साथ।

मैंने यह भी नोट किया कि वे SQL को कोडर्स की सलाह देते हैं। मैं सहमत हूँ। यह एक कंप्यूटर प्रोग्रामिंग भाषा है, इसलिए मैं यह नहीं देखता कि कंप्यूटर प्रोग्रामर इसे क्यों नहीं जानना चाहेंगे।

बाद में, इसके बारे में सोचने के बाद

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


5
मैं वास्तव में डेटाबेस गिरावट बिंदु का पालन नहीं करता; डेटाबेस में तर्क डालकर, आपको केवल एक ही स्थान पर (डेटाबेस) नियमों को बदलने की आवश्यकता है न कि कई भाषाओं में लिखे गए एप्लिकेशन। हालांकि एक अच्छी तरह से सोचा प्रतिक्रिया के लिए +1।
फिल लेलो

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

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

1
@ChristopherMahan, खराब डेटा को रोकने के लिए डेटाबेस डिज़ाइन में आप बहुत कुछ कर सकते हैं।
HLGEM

4

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

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

डीबीए स्टैक एक्सचेंज में एक उपयोगकर्ता ने यह कहा ...

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

पिछले फॉर्च्यून 500 में मैंने काम किया था जिसमें कम से कम 25 भाषाओं में उनके ओएलटीपी डेटाबेस को मारते हुए आवेदन लिखे गए थे। उन कार्यक्रमों में से कुछ 1970 के दशक में उत्पादन में चले गए।

... उनके इस विश्वास से कि यह DRY सिद्धांत के उल्लंघन का संकेत है।

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

उनका ओएलटीबी डेटाबेस दशकों से 25+ अनुप्रयोगों के लिए मज़बूती से और कुशलता से डेटा प्रदान कर रहा है! वह आश्चर्यजनक है! (जाने के लिए रास्ता!)

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

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


ख़ूब कहा है। संग्रहीत प्रक्रियाओं, संदर्भात्मक अखंडता आदि के साथ मेरा बड़ा बग त्रुटि से निपटने में है। सभी अक्सर अंत उपयोगकर्ता को "शॉकिंग एरर ऑब्जेक्ट ऑब्जेक्ट YYYY प्रक्रिया XXXXXX - sqlcode -666" के साथ प्रस्तुत किया जाता है, जिसके परिणामस्वरूप समय कॉल समर्थन बर्बाद होता है। जब एक सरल "ग्राहक के पास कोई टैक्स आईडी नहीं है" तो उपयोगकर्ता को समस्या को ठीक करने और अपनी नौकरी के साथ आने देगा।
जेम्स एंडरसन

3

डेटाबेस अज्ञेय अनुप्रयोगों डेटाबेस से बाहर सभी तर्क की आवश्यकता है। कई अलग-अलग डेटाबेस प्रदाताओं के लिए कोड बनाना और बनाए रखना बहुत कठिन है।


3
आवेदन आधारित तर्क के साथ एप्लिकेशन अज्ञेय डेटा गोदामों का निर्माण करना बहुत कठिन है
फिल लेलो

3

एक अच्छा विकास डेटाबेस में तर्क के कुछ और आवेदन में इसे डालकर डेटाबेस की अखंडता और गति की आवश्यकता के बीच एक अच्छा संतुलन होगा।

क्या एक ही क्वेरी का उपयोग कई अनुप्रयोगों में बार-बार किया जाएगा, फिर शायद यह एक संग्रहीत प्रक्रिया में है।

यह सुनिश्चित करना कि एक पंक्ति डालने और अद्यतन किए जाने पर घर रखने वाले फ़ील्ड सेट किए जाते हैं, एक DBA जिम्मेदारी है। एक ट्रिगर का उपयोग किया जाएगा।

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

यह टीमों के बीच संचार का मामला है और प्रत्येक संभावनाओं के लिए पेशेवरों और विपक्षों को पहचानने का मामला है।

मेरी राय है: डीबी में आवेदन का तर्क बहुत गहरा मत करो।


2

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

आप एक डेटाबेस में तर्क रखेंगे, क्योंकि आप उस तर्क को आसानी से संशोधित करने में सक्षम होना चाहते हैं।

  • आप संस्करण नियंत्रण कैसे करेंगे?
    • कोड इतिहास क्या है? बदलाव क्या थे? किसके द्वारा?
    • आप एक ही कोड अंशों में परिवर्तन कैसे संभालते हैं?
  • आप एक सुसंगत कोड राज्य की पहचान और गारंटी कैसे देंगे?

आप इसे एक अतिरिक्त फ़ाइल-आधारित VCS में ट्रैक कर सकते हैं, लेकिन तब डेटाबेस का क्या लाभ है?


सभी डेटाबेस कोड किसी भी घटना में स्रोत नियंत्रण में होना चाहिए। यह किसी अन्य की तरह कोड है।
HLGEM

1

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.