आवेदन कोड लिखे जाने से पहले क्या आपको डेटाबेस डिजाइन करना चाहिए?


57

डेटाबेस डिजाइन करने के लिए सबसे आसान और सबसे कुशल तरीका क्या है? मेरे दृष्टिकोण से, एप्लिकेशन के डेटा स्टोर डिज़ाइन के लिए कुछ विकल्प हैं:

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

आपके अनुभव में, आपको सबसे अधिक उत्पादक और कुशल तरीका क्या लगता है?



1
आपको flywaydb.org दिलचस्प लग सकता है । यह आपको अपने डेटाबेस स्कीमा को नियंत्रित करने की अनुमति देता है।
थोरबजोरन रावन एंडरसन

जवाबों:


41

अन्य उत्तरों के अलावा ...

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

एक बार जब यह ज्यादातर स्थिर हो जाता है, तो आपके पास अपने आवेदन के निर्माण के लिए एक स्थिर डेटाबेस होता है। यह आपके पहले विकल्प के विपरीत है।

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

स्कीमा में मामूली परिवर्तन, तालिकाओं को जोड़ना या विभाजित करना, रिश्तों को बदलना आदि होगा, लेकिन स्थानीय "द्वीपों" और आपके मॉडल + मूल डिज़ाइन में परिवर्तन नहीं होगा।


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

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

@ जिंकिंग: मैं इसे फुर्तीली बात अभी कर रहा हूं।
gbn

@ क्षमा करें, यहाँ नीचे प्रश्न पूछने के लिए क्षमा करें। मुझे नहीं पता कि परिदृश्य को कैसे संभालना है। कृपया एक नज़र डालें। stackoverflow.com/questions/46285924/… । कृपया मुझे बेहतर समाधान सुझाएं।
आरजीएस

27

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

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

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

मुझे लगता है कि अपने विकल्प 2 के साथ अपना वोट डालता है और मुझे संदेह है कि मैं इस ठंड में खुद को खड़ा पा सकता हूं!


4
फुर्तीली और डेटाबेस कैविट्स के साथ एक साथ चलते हैं। एजाइल वीएलडीबी के लिए सीमा रेखा है: डिलिवरेबल्स के बीच अरब पंक्ति तालिकाओं में बदलावों को मान्य और परीक्षण करने के लिए पर्याप्त समय नहीं हो सकता है। और "फुर्तीली विकास" पूर्वविवेक की कमी के कारण "थोक परिवर्तन" के समान नहीं है
gbn

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

3
मैंने प्रश्न को "अभी तक कोई DB के साथ एक नया ऐप" नहीं पढ़ा है, बल्कि "एक मौजूदा ऐप जिसे DB में बदलाव की आवश्यकता है"
gbn

इसी तरह, मुझे आपकी बात कहीं याद आ रही है :) चैट करने के लिए एक?
मार्क स्टोरी-स्मिथ

4
आपके उत्तर की सामान्य भावना के लिए +1, लेकिन "डेटाबेस स्कीमा को संशोधित करना कोड को संशोधित करना कभी भी उतना आसान नहीं था" वास्तव में यह निर्भर करता है कि आपके पास कितना कोड है (और यह कितना पुराना है)। आईएमओ इसके विपरीत आम तौर पर सच है
जैक डगलस

12

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

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

  1. स्कोप रेंगना - आप अनुचित समय पर नई आवश्यकताओं को पेश करने की अनुमति दे रहे हैं।
  2. अपर्याप्त व्यावसायिक आवश्यकताएँ - आपके डेटा मॉडलर (या सिस्टम विश्लेषक) ने व्यावसायिक विश्लेषकों की आवश्यकताओं का पर्याप्त अनुवाद नहीं किया। यह आपके आवेदन की आवश्यकताओं का समर्थन करने के लिए एक अधूरा या गलत डेटा मॉडल के परिणामस्वरूप हुआ।

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

उम्मीद है की यह मदद करेगा।


7
किसी परियोजना के दौरान बहुत सी नई आवश्यकताओं को जोड़ना "अनुचित" नहीं है। यह कुछ ऐसा है जिसे आपके विकास के तरीकों का समर्थन करने और प्रोत्साहित करने के लिए www.agilemanifesto.org/principles.html
nvogel

1
मैं चुस्त विकास के कुछ सिद्धांतों से अच्छी तरह वाकिफ हूँ और एक डेटा भण्डारण क्षमता में उनका प्रस्तावक रहा हूँ जहाँ यह व्यवसाय के लिए समझ में आता है। आपके कमेंट के लिए धन्यवाद।
RobPaller

11

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

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

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

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

मैं अच्छा हूँ जो मैं करता हूँ। लेकिन मुझे केवल एक ही वातावरण में ऐसा करना है जो "विकास नहीं करता है।"

यह सब कहा, मैं व्यापार नियमों की खोज में बेहतर हो रहा हूं। और मुझे एक तीसरा विकल्प दिखाई देता है:

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

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

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

मेरी राय में, यह एक बहुत बड़ी जीत है।


+1 महान जवाब। कई आवश्यकताओं वाले परियोजना में सुविधा आवश्यकताओं का विकास एक बड़ा प्लस है।
ज़ायेन एस हल्सल

10

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

यह परियोजना अनुशासन की एक निश्चित राशि लेता है। हर बार जब आप डेटाबेस में बदलाव करते हैं तो सामान्य रूप से सामान्य रूप से लागू करें (Boyce-Codd / Fifth Normal Form) ताकि आप गुणवत्ता बनाए रखें और एक तदर्थ और असंगत मॉडल के साथ समाप्त न हों। व्यापार नियमों और परिचर डेटाबेस बाधाओं के साथ जितना संभव हो उतना आक्रामक हो। यदि संदेह है कि जल्दी से एक बाधा को लागू करना बेहतर है - आप इसे हमेशा बाद में निकाल सकते हैं। तकनीकी ऋण को कम करने के लिए आप वास्तु घटकों को लागू करने वाले आदेश के बारे में बुद्धिमान रहें। डेटाबेस डिजाइन दिशा निर्देशों का एक अच्छा सेट है जो सभी देव टीम में खरीदते हैं।

यह सब निश्चित रूप से अन्य अच्छे विकास इंजीनियरिंग प्रथाओं के साथ हाथ से जाने की जरूरत है: निरंतर एकीकरण, परीक्षण स्वचालन और डेटाबेस परिप्रेक्ष्य से महत्वपूर्ण रूप से, परीक्षण डेटा का निर्माण। वास्तविक रूप से आकार के डेटा का परीक्षण डेटा निर्माण बिना असफलता के प्रत्येक पुनरावृत्ति में किया जाना चाहिए।


2
क्या आपको नहीं लगता कि वैचारिक मॉडल को परिभाषित करने के लिए कुछ अग्रिम सोच की आवश्यकता होगी?
gbn

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

मुझे संदेह है @dportas और मैं इसी तरह के वातावरण में काम करते हैं :)
मार्क स्टोरी-स्मिथ

9

वास्तुकला की दुनिया में, "फॉर्म फॉलो फंक्शन" वाक्यांश गढ़ा गया था और बाद में ऊंची इमारतों का निर्माण करते समय इसका पालन किया गया था। इसे डीबी इंफ्रास्ट्रक्चर और एप्लीकेशन डेवलपमेंट पर लागू किया जाना चाहिए।

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

दुर्भाग्य से, कुछ डेवलपर दुकानें मेमेकैक्ड की तरह कुछ उठाती हैं, इसे रैम में डेटा के साथ लोड करती हैं (इस तरह इसे एक डेटा नाली के रूप में मानती हैं), और एक डेटाबेस है, जैसे MySQL या PostgreSQL, बस डेटा स्टोरेज यूनिट के रूप में व्यवहार करते हैं।

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

निष्कर्ष

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


1
@RolandoMySQLDBA, आप यह मान रहे हैं कि ऐप डेवलपमेंट के दौरान बनाया गया एक डेटाबेस डिज़ाइन पहले से निर्मित एक खराब डिज़ाइन होगा? क्यों? विपरीत अक्सर सच होता है।
nvogel

1
@ डोप्रास: डीबी डिजाइन में बदलाव को कम करने के संदर्भ में मेरा जोर विकल्प 1 पर है। मैंने अपनी तकनीक कैरियर प्रोग्रामिंग के 2/3 खर्च उन दुकानों में किए जहां बहुत जटिल डेटा मॉडल और बुनियादी ढांचे को लगभग मासिक रूप से जोड़ा जा रहा था। मैंने ऐसे बदलावों पर ध्यान दिया क्योंकि व्यवसाय की जरूरत और लक्ष्य पत्थर में नहीं थे। मैं इसमें काफी पुराना स्कूल हूं। जब तक डिजाइन बहुत 'तकनीकी ऋण' का उत्पादन नहीं करता है, तब तक थोड़ा मोटा होने के साथ कुछ भी गलत नहीं है (हाँ, मैंने आपको जवाब पढ़ा) सड़क के नीचे।
रोलैंडमाइसीडीडीबीए

2
+1 के लिए 'एक रिलेशनल डेटाबेस के रूप में RDBMS का उपयोग सरणियों के लिए बिट-बकेट नहीं' - जो भी आप लेते हैं
जैक डगलस

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

3
@ डीडीपोर्ट: सभी DB परिवर्तन नहीं, केवल RADICAL हैं। मामूली परिवर्तन सॉफ्टवेयर करने के व्यवसाय का हिस्सा हैं। लेकिन काम के बीच में 2 अलग-अलग डेटाबेस में डेटा को विभाजित करने के लिए डिज़ाइन और कैप्चरिंग व्यावसायिक नियमों पर विफलता है। (यह वास्तव में मेरे साथ हुआ।
फैब्रिकियो आरुजो

9

मुझे लगता है कि यह आवेदन के लिए कोई वास्तविक कोड होने से पहले किया जाना चाहिए , लेकिन आवेदन के डिजाइन से पहले नहीं।

मेरा विशिष्ट वर्कफ़्लो, यदि अकेले काम करना है:

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

जैसा कि मैं अक्सर एक टीम के हिस्से के रूप में काम करता हूं, और हम भौगोलिक रूप से फैले हुए हैं (और समय क्षेत्र में), हम एक प्रारंभिक किकऑफ बैठक करते हैं:

  1. निर्धारित करें कि एप्लिकेशन को क्या करना है।
  2. निर्धारित करें कि एप्लिकेशन को स्व-निहित घटकों में तोड़ने के लिए अच्छे अंक कहां हैं
  3. निर्धारित करें कि प्रत्येक घटक को दूसरों के साथ बातचीत करने की आवश्यकता कैसे होगी।
  4. प्रत्येक इंटरैक्शन के लिए API पर सहमत हों।

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


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

8

मेरे पास फॉलोइंग नियम का ध्यान है: "आप केवल डेटाबेस से वह जानकारी प्राप्त कर सकते हैं जो आपके पास उत्पन्न करने के लिए डेटा है"। इसलिए, मैं पहले डेटाबेस को बाद में कोड डिजाइन करता हूं।

क्यों? कोई फर्क नहीं पड़ता कि मैं क्या मेटोडोलॉजी / भाषा / टूलसेट का उपयोग करता हूं, अगर सभी प्रासंगिक डेटा को अच्छी तरह से डिज़ाइन किया गया है और डीबी I में संग्रहीत किया गया है। कोई बात नहीं अगर C # / डेल्फी / FORTRAN / COBOL / विधानसभा / VBA या क्रिस्टल रिपोर्ट में है; OO द्वारा डिज़ाइन या ईवेंट / डेटा / जो भी संचालित हो; फुर्तीली या झरना। यदि डेटा है, तो मैं इसे पुनः प्राप्त कर सकता हूं यदि मेरे द्वारा उपयोग किए जाने वाले उपकरण डेटाबेस से जुड़ सकते हैं। यदि मैं तिमाही के राजस्व के लिए आदेशों का चयन कर सकता हूं, तो मैं बिक्री रिपोर्ट बना सकता हूं - भले ही मुझे इसे विधानसभा पर बाइट-बाइट लिखना पड़े।

यदि प्रासंगिक डेटा वहां नहीं है या भले ही वह वहां है, लेकिन (संयुक्त राष्ट्र) एक तरह से संरचित है, जो मुझे आवश्यक जानकारी को पुनः प्राप्त नहीं कर सकता है - उसे कैसे कोडित करें?


7

आमतौर पर, यह निर्भर करता है;)

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

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

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