2009-04-17 12 views
5

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

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

उत्तर

2

यदि आपके पास डेटाबेस को हिट करने वाला अच्छा परीक्षण है, तो मैं आपके डेटाबेस डिज़ाइन में YAGNI का विस्तार करूंगा।

सामान्यतः, कॉलम और तालिकाओं को जोड़ना आसान होता है, और उन्हें हटाने या संशोधित करने में कम आसान होता है। जब आप तालिकाओं को डिज़ाइन करते हैं तो इसे ध्यान में रखें (यानी यदि ग्राहक के पास एकाधिक उपयोगकर्ता हो सकते हैं, तो अपने ग्राहक तालिका में उपयोगकर्ता जोड़ें नहीं। इसे पहली बार सही करें)।

+0

क्या होगा यदि आप इसे चारों ओर फ़्लिप करते हैं: कहें कि क्लाइंट के विनिर्देश वर्तमान में प्रति कलाकार एक कलाकार के लिए हैं, लेकिन भविष्य में उनके दो बैंड एक साथ दौरे पर जा सकते हैं, इस प्रकार एक ही शो में खेलते हैं। क्या आप अभी भी टूर्नामेंट टेबल में artist_id जोड़ते हैं, सिस्टम को 1 कलाकार प्रति टूरडेट तक सीमित करते हैं? या क्या आप आगे सोचते हैं, इसे एक हाबेट रिश्ते बनाते हैं? – Calvin

2

मेरी राय यह है कि YAGNI सब कुछ, कोडिंग, डेटाबेस डिज़ाइन, घर के आसपास काम करने पर लागू होता है (मेरी पत्नी मेरे साथ इस बात से असहमत है), और इसी तरह।

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

लेकिन यही वह है जो वे वहां हैं।

3

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

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

+0

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

+0

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

0

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

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

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

कक्षा जोड़ने के रूप में एक स्कीमा को ट्विक करना आसान नहीं है, लेकिन यह करने योग्य है।

तो कुल मिलाकर, YAGNI अभी भी लागू होता है।

0

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

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

2

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

0

डेटाबेस डिज़ाइन किसी अन्य प्रकार की डिज़ाइन की तरह है। आपकी समझ बढ़ती जा रही है, और बेहतर समझ के साथ एक विकसित स्कीमा आता है।

मेरी इच्छा है कि यह समझाना आसान हो कि वास्तव में डेटाबेस स्कीमा डिज़ाइन के संबंध में एक वैचारिक आधार कैसा है। एकमात्र उपकरण जो वास्तव में मॉडल करता है वह ऑब्जेक्ट रोल मॉडलिंग है, जो लंबे समय से उभर रहा है। सबसे परिचित उपकरण Visiomodeler था। इसका स्वाद प्राप्त करने के लिए, यहां Scott Ambler और Scot Becker के कुछ लिंक दिए गए हैं लेकिन निष्कर्ष निकाला जाएगा कि ऑब्जेक्ट-मॉडलिंग-प्रकार के दावे सीधे एक विशिष्ट संबंधपरक लॉजिकल मॉडल पर ले जाते हैं; इसलिए आपके वैचारिक मॉडल में परिवर्तन के रूप में स्कीमा को बदलने की आवश्यकता होगी।

प्रैक्टिस में, यदि आप परिवर्तन अभिव्यक्तियों के साथ वास्तव में सहज हैं तो आपके rdbms काफी फ्लेक्सिंग को संभाल सकते हैं; और इसमें अच्छा होने के लायक है।

नोट: मुझे लगता है कि LINQ और ऑब्जेक्ट-रिलेशनल मॉडल जैसे एसक्यूएल टावरेंस तकनीक सिर्फ एक विकसित डिज़ाइन में बाधा होगी। शायद मैं गलत हो सकता हूँ। आशा करने का कोई कारण है कि माइक्रोसॉफ्ट के एंटिटी फ्रेमवर्क में ऑब्जेक्ट रोल मॉडलिंग शामिल होगा; लेकिन मैंने केवल संभावना के लिए तिरछे संदर्भ देखे हैं।

1

डेटाबेस डिज़ाइन के लिए एक वैचारिक आधार है।

शास्त्रीय डेटाबेस डिज़ाइन में, तीन मॉडल हैं: वैचारिक, तार्किक और भौतिक।

वैचारिक मॉडल आवश्यकताओं के विश्लेषण से उभरता है, और अंतर्निहित विषय वस्तु विकसित होती है या विषय वस्तु की समझ विकसित होती है। वैचारिक मॉडल प्राथमिक डेटा को फॉर्म और अर्थशास्त्र के रूप में पिन करता है, लेकिन तालिका संरचना के रूप में ऐसे मुद्दों से निपटता नहीं है।

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

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

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

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

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

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

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

संबंधित मुद्दे