संबंधपरक डेटाबेस और पुनरावृत्त विकास


19

सॉफ्टवेयर विकास के कई दृष्टिकोण जैसे कि चुस्त कार्यप्रणाली, डोमेन-संचालित डिज़ाइन और ऑब्जेक्ट ओरिएंटेड एनालिसिस एंड डिज़ाइन, हमें विकास के लिए एक पुनरावृत्त दृष्टिकोण लेने के लिए प्रोत्साहित किया जाता है।

इसलिए जब हम प्रोजेक्ट में काम करना शुरू करते हैं, तो हम अपने डोमेन मॉडल को सही तरीके से पूरा नहीं कर पाते हैं। इसके बजाय, जैसा कि समय के अनुसार हम मॉडल को रिफलेक्टर करते हैं क्योंकि हम समय के साथ समस्या डोमेन की गहरी समझ प्राप्त करते हैं।

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

यहां मुद्दा यह है कि सॉफ्टवेयर को लागू करने के बाद हमें मॉडल को बदलने की आवश्यकता हो सकती है। यदि ऐसा होता है तो हमारे पास एक समस्या है: उत्पादन डेटाबेस में उपयोगकर्ता का डेटा है जो महत्वपूर्ण है और पुराने मॉडल के प्रारूप में पहले से ही फिट है

यदि कोड अच्छी तरह से डिज़ाइन नहीं किया गया है और सिस्टम बड़ा है तो कोड को अपडेट करना एक कठिन काम हो सकता है। लेकिन यह समय के साथ किया जा सकता है, हमारे पास गिट जैसे उपकरण हैं जो उत्पादन-तैयार संस्करण को नुकसान पहुंचाए बिना हमें ऐसा करने में मदद करते हैं।

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

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

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

यह दृष्टिकोण सबसे अच्छा नहीं लगता है। मेरा सवाल यहाँ है: क्या संबंधपरक डेटाबेस के साथ पुनरावृत्ति विकास को समेटने के लिए कोई जाना-पहचाना और पुनःप्राप्त दृष्टिकोण है?


6
संयोग से, मुझे नहीं लगता कि इसका संबंध विशेष रूप से संबंधपरक डेटाबेस से है। मेरे पास एक ऐसी समस्या है जिस पर मैं काम कर रहा हूं, लेकिन हम इसे हमारे JSON स्ट्रिंग्स के लिए स्कीमा के साथ कर रहे हैं जो बहुत ही गैर-संबंधपरक वस्तुओं का प्रतिनिधित्व करते हैं। यह संभवतः दृढ़ता के सभी रूपों को समान रूप से प्रभावित करता है।
Ixrec

1
आप डेटाबेस स्कीमा को ऐसे तरीके से बदलते हैं जिसमें डेटा नहीं खोता है, en.wikipedia.org/wiki/Schema_migration
रेमकोगर्लिच

1
मुझे यकीन है कि इस विषय पर पहले कहीं व्यापक रूप से चर्चा की गई थी, बस इसे प्रोग्रामर पर नहीं पाया जा सकता है। लेकिन यहां देखें martinfowler.com/articles/evodb.html या यहाँ stackoverflow.com/questions/334059/…
डॉक्टर ब्राउन

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

जवाबों:


15

इसमें विशेष कक्षाएं नहीं होती हैं, लेकिन हां, आपको कुछ ऐसा चाहिए जो डेटाबेस को पिछले प्रारूप में ले जाएगा और इसे वर्तमान में बदल देगा।

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

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

और सुनिश्चित करें कि आप कभी भी लिपियों को लागू करके और साझा नहीं करने पर किसी भी साझा किए गए devel, परीक्षण और QA वातावरण को संशोधित करते हैं यदि वे काम नहीं करते हैं, तो आप उचित रूप से आश्वस्त हो सकते हैं कि जब आप उन्हें उत्पादन में लाएंगे तो वे इच्छित उद्देश्य के साथ काम करेंगे। ।

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

@ डॉक ब्राउन ने पहले से ही मार्टिन फाउलर को जोड़ा : इवोल्यूशनरी डेटाबेस डिज़ाइन और /programming/334059/agile-development-and-database-changes , और मैं एलेक्स पापडिमौलिस, डेटाबेस चेंजेस डोन राइट , जो छोटा है और कुछ उदाहरण हैं।

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


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

1
एलेक्स के लेख के लिए अंगूठे; यह कम नहीं हो सकता है, लेकिन यह बहुत अधिक अभ्यास उन्मुख और मनोरंजक रीड बनाता है।
मर्फी

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

1

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

सबसे पहले और सबसे महत्वपूर्ण, एक संबंधपरक डेटाबेस डेटा मॉडल को बहुत अधिक बाधित करता है, जिससे परिवर्तन बहुत मुश्किल हो जाता है?

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

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

यह प्रश्न के दूसरे भाग की ओर जाता है, जो वास्तव में एक धारणा से अधिक था, लेकिन एक प्रश्न के रूप में देखा जाना चाहिए: क्या हम पहली बार अपने डोमेन मॉडल को सही तरीके से प्राप्त करने वाले हैं?

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

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

यह अंतिम प्रश्न की ओर जाता है: एक संबंधपरक डेटा मॉडल है जो चुस्त दृष्टिकोण के साथ असंगत है?

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


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

हां, लेकिन यह कभी भी सिर्फ एक क्षेत्र नहीं है ...
theMayer

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

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

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

-1

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

यह आपको आने वाले बड़े परिवर्तनों को संभालने के लिए 2 मुख्य विकल्प प्रदान करता है: पहला है डीबी परत को एक एपीआई के रूप में बनाना, संग्रहीत प्रक्रियाओं का उपयोग करना ताकि उन्हें अंतर्निहित डेटा स्कीमा को बदलने के बिना क्लाइंट को सूट करने के लिए बदला जा सके।

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

तो: 1. डिजाइन के साथ आगे सोचने की कोशिश करें ताकि आपको चीजों को बदलने की आवश्यकता न हो।

  1. रैपर या एपीआई पर निर्भर है इसलिए परिवर्तन सीमित है या एक पृथक घटक के अंदर छिपाया जा सकता है

  2. अगर आपको करना है तो ठीक से अपग्रेड करने के लिए समय निकालें।

ये कदम सिर्फ डेटाबेस ही नहीं, हर चीज पर लागू होते हैं।


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

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

आपको अभी भी एसपी को स्थापित करने और नए क्षेत्र को जोड़ने के लिए प्रत्येक ग्राहक साइट पर जाना होगा। और जब आप वहां होते हैं, तो आप डेटा को माइग्रेट भी कर सकते हैं। एसपी उपयोगी होते हैं कि वे आपको पिछड़े संगत इंटरफ़ेस बनाने की अनुमति देते हैं यदि आपके पास कई एप्लिकेशन डेटाबेस तक पहुंचते हैं, तो आपको उन सभी को एक ही समय में अपग्रेड करने की आवश्यकता नहीं है। लेकिन बदलती आवश्यकताओं के कारण स्कीमा को बदलने की आवश्यकता होने पर वे कोई कदम नहीं बचाते हैं।
Jan Hudec
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.