नई सुविधाओं को संभालने के लिए डेटाबेस को फिर से तैयार करना या अपग्रेड करना

9

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

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

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

— JeffO
स्रोत

1

+1 यह पूछने के लिए धन्यवाद। मैंने अपने मूल प्रश्न की प्रतिक्रियाओं को पढ़कर बहुत कुछ सीखा, और यह एक व्यावहारिक धागा भी है।

— जिम

3

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

आप यहाँ डेटाबेस रीफ़ैक्टरिंग के बारे में अधिक पढ़ सकते हैं ।

— प्रमोद
स्रोत

यह साइट वही है जो पहली बार में सवाल का संकेत देती है;)

— जेएफओ

14

कोड को फिर से भरना आसान है - आप बस कोड को बदलते हैं और अपने प्रतिगमन परीक्षण चलाते हैं।

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

डरावनी चीज़ें।

— मैथ्यू फ्लिन
स्रोत

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

— जेएफओ

8

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

— एंजेलो

2

कभी-कभी अरबों पंक्तियाँ

— HLGEM

1

यदि आप अरबों पंक्तियों के साथ काम कर रहे हैं, तो आप बेहतर जानते हैं कि उन्हें कैसे स्थानांतरित किया जाए

— जेएफओ

3

बहुत-से समय इंजीनियरिंग में बिताने और अपना थोड़ा-सा समय निवेश करने के बीच एक ठीक-ठाक रेखा है, ताकि भविष्य में आपके पास काफी समय बचा रहे।

— 0x4B1D
स्रोत

1

आप एक अलग उदाहरण या दो के लिए यह तर्क कर सकते हैं, लेकिन समय के 'बिट्स' कब तक जोड़ते हैं?

— जेएफओ

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

— 0x4B1D

@ जेफ ओ: यह 'बिट्स' होने वाला नहीं है। सख्त होने में विकास के समय का 10% या 20% निवेश आवश्यक है क्योंकि सिस्टम मूल रूप से लागू समय सीमा और आपके रोजगार दोनों को समाप्त कर सकता है।

— रवांग

3

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

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

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

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

IMHO इसकी जरूरत नहीं होगी अगर हमारे पास संबंधपरक बीजगणित को निर्दिष्ट करने के लिए SQL से बेहतर भाषा हो। यदि यह ऑब्जेक्ट द्वारा SQL तालिका के टुकड़े का निर्माण करने के लिए संभव था, तो ऐसा होने वाली क्वेरी में प्रत्येक तालिका को दृश्यता की आवश्यकता नहीं थी। LINQ (SQL या Entities के लिए) जैसी चीजें इसे हल करने का प्रयास करती हैं, लेकिन यह अनुकूलन के लिए एक बहुत ही जटिल समाधान और कठिन है (और मैं DBA उपयोगकर्ता समूहों में गया हूं जहां LINQ का उल्लेख किया गया है और एक सामूहिक कमर हर बार ऊपर जाती है)। मैं एक ऐसी डेटाबेस भाषा का सपना देखता हूं, जो सर्वप्रथम प्रथम श्रेणी के रिलेशनल बीजगणित कार्यों के साथ समर्थित हो ...

इस बीच, हां, आप 1-से-कई से कई-से-कई तक रिफ्लेक्टर कर सकते हैं, लेकिन यह बहुत काम हो सकता है।

— psr
स्रोत

आप हर रिश्ते को कई-कई में नहीं बदलेंगे?

— जेएफओ

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

— Psr

3

मैं आमतौर पर इसे पीएचबी के लिए इस तरह से समझाता हूं - कोड दीवारों और छत है, डेटाबेस नींव है।

दीवारों को हिलाने और छत को बदलने का काम किया जा सकता है। नींव को चारों ओर बदलने के लिए दीवारों और छत को खोदने और पुनर्निर्माण करने की बहुत आवश्यकता होती है।

क्या अनुभवहीन डेवलपर्स (और कॉलेज के प्रोफेसरों) का कहना है कि "ओवर इंजीनियरिंग" है जो अनुभवी डेवलपर्स "भविष्य के प्रमाण" कहते हैं। इसके बावजूद कि युक्ति क्या कहती है कि आपको पता है कि ALM के दौरान क्या परिवर्तन होगा या जहां प्रदर्शन समस्याएं होंगी, इसलिए आप अपनी तालिका संरचना को प्रारंभ करने के लिए सही प्राप्त करना चाहते हैं।

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

— JQA
स्रोत

1

सामान्य नियम है, तो एक रिश्ते से एक करने के लिए एक है लेकिन है हो सकता है भविष्य में कई के लिए कई तो यह कई लोगों के लिए एक बहुत बनाने के लिए किया।

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

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

— जेम्स एंडरसन
स्रोत

मैं मानता हूं कि कई परिपक्व डोमेन (जैसे एचआर) हैं जहां ग्राहक की आवश्यकता का अनुमान नहीं है, लेकिन आप जानते हैं कि ऐसा होने के लिए बाध्य है।

— जेएफओ

0

सॉफ्टवेयर के डिजाइन को देखने के दो तरीके हैं (और शायद कई अन्य चीजें) - एक सामरिक दृष्टिकोण या एक रणनीतिक दृष्टिकोण। प्रत्येक का अपना फायदा और कमियां हैं।

OO सॉफ्टवेयर संशोधनों के साथ अभी भी एक दर्द है, न केवल कोडिंग भाग मुश्किल है, बल्कि एक शिकायत वातावरण में उत्पादन में बदलाव को बढ़ावा देने की प्रक्रिया (तकनीक की वर्तमान स्थिति को देखते हुए) बड़ी प्रणालियों के लिए असत्य है जो माना जाता है। काम 24/7।

मैं अपने सिद्धांत का पालन करता हूं जो कहता है: " जब संभव हो, तो डिज़ाइन किए गए सॉफ़्टवेयर कलाकृतियों को रणनीतिक रूप से डिज़ाइन करें " - यह लग सकता है जैसे यह किसी तरह से YAGNI सिद्धांत के खिलाफ जाता है, हालांकि, यह मेरी राय है। यह दृष्टिकोण जटिलता और संसाधनों की लागत पर कम पुनः काम की गारंटी देता है।

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

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

इसलिए, इसे शुरू से ही समझ लेना बेहतर है।

— कोई मौका नहीं
स्रोत

शुरुआत से ही सब कुछ बेहतर है।

— जेएफओ

0

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

— mbaylon
स्रोत