2010-07-24 13 views
9

के साथ काम कर रहे सर्वोत्तम अभ्यास टीम डीबी पर काम करने वाली टीम के लिए बेहतर क्या है? क्या यह प्रत्येक डेवलपर या साझा डेटाबेस के लिए स्थानीय डेटाबेस उदाहरण है?डेटाबेस

+0

यह निर्भर करता है कि डेटाबेस स्कीमा कैसे डिज़ाइन किया गया है (यदि इसे डिज़ाइन किया गया है), परीक्षण डेटा कितना जटिल है, डेटाबेस स्कीमा कितना स्थिर है, और सामग्री। विकास में प्रगति के साथ यह भिन्न हो सकता है। – pascal

+0

बीडी क्या है? क्या यह डीबी का एक टाइपो है, या कुछ उत्पाद मैंने नहीं सुना है? –

+0

मुझे यह आलेख मिला: http://odetocode.com/blogs/scott/archive/2008/01/30/three-rules-for-database-work.aspx लेकिन मैं "पास्कल" से सहमत हूं यह डेटाबेस पर निर्भर करता है आकार, स्कीमा और अन्य विशेषताओं। – k0stya

उत्तर

12

मेरे अनुभव में एक टीम को (कम से कम) एकीकृतकरण के लिए एक साझा डेटाबेस होना चाहिए।

विकास के दौरान प्रत्येक टीम के सदस्य के पास एक अपरिचित डेटाबेस होना चाहिए अन्यथा डेटाबेस स्कीमा के परिवर्तन अन्य टीम के सदस्यों को बाधित कर सकते हैं। ये उदाहरण एक केंद्रीकृत सर्वर पर भी हो सकते हैं।

1

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

मेरे पास विकास के लिए एक साझा डेटाबेस होगा। विविध परीक्षण के लिए हमारे पास एक या दो देव डेटाबेस भी थे।

+0

किसी अन्य मामले में अगर किसी ने डेटाबेस में कॉलम प्रकार बदल दिया है और ओआरएम स्कीमा अपलोड नहीं किया है? – k0stya

+1

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

4

मैं एक ही तरीका है के बारे में टीम मैं वर्तमान में काम करता है में हूँ, जो हमारी जरूरतों काफी अच्छी तरह से फिट बैठता है बात कर सकते हैं:

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

हम एकीकरण निर्माण के माध्यम से केंद्रीय डेटाबेस उदाहरण पर किसी अन्य तरीके से स्कीमा परिवर्तन की अनुमति नहीं देते हैं। स्कीमा परिवर्तन स्क्रिप्ट को विकसित करने के लिए, अलग-अलग डेटाबेस उदाहरण पर, केंद्रीय सर्वर पर या स्थानीय रूप से (व्यक्तिगत वरीयता के आधार पर) परिवर्तन अलग-अलग होते हैं।

4

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

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

Jeff Atwood has a pretty good article on source controlling database code.

अलग डेवलपर्स माना जाता है कि विभिन्न मुद्दों पर काम करते हैं - आप अन्य लोगों के पैर की उंगलियों, जबकि इकाई परीक्षण पर कदम रख कैसे से बचने के हैं?

मैं पूरी तरह से एकीकरण/परीक्षण वातावरण की वकालत करता हूं, जिसे Continuous Integration process के माध्यम से अपडेट किया जाता है। यह पर्यावरण अक्सर आपकी तैनाती प्रक्रिया के लिए लिटमस परीक्षण के रूप में भी कार्य करता है।

3

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

डेटाबेस डेवलपर्स से बात करने के हमारे अनुभव में, साझा वातावरण पर लगभग आधा डेटाबेस विकास किया जाता है, और प्रति समर्पित डेवलपर वातावरण पर आधे।

1

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

लेकिन एकमात्र समस्या एक दूसरे के साथ समन्वय में एकाधिक enviornment रखना है क्योंकि किसी भी लापता परिवर्तन घातक हो सकता है।

+0

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

1

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

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