2010-06-28 12 views
17

चार लोगों की मेरी विकास टीम को कुछ समय के लिए इस मुद्दे का सामना करना पड़ रहा है:विकास के दौरान डेटाबेस कैसे प्रबंधित करते हैं?

कभी-कभी हमें डेटा के उसी सेट से काम करने की आवश्यकता होती है। इसलिए जब हम अपने स्थानीय कंप्यूटर पर विकसित होते हैं, तो देव डेटाबेस दूरस्थ रूप से कनेक्ट होता है।

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

क्या इस दुविधा के आसपास होने का सबसे अच्छा अभ्यास है? क्या "डेटा के लिए एससीएम" उपकरण की तरह कुछ है?

अजीब तरीके से, गिट रेपो में एसक्यूएल डालने/हटाने/अपडेट क्वेरीज़ की एक टेक्स्ट फ़ाइल रखना उपयोगी होगा, लेकिन मुझे लगता है कि यह बहुत धीमी गति से हो सकता है।

आप लोग इस से कैसे निपटते हैं?

+1

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

+0

सही समझ में आता है :) यह चार की टीम के लिए अधिकतर ठीक काम करता है। जैसे-जैसे हमारी टीम बढ़ती है (जो बहुत संभावना है), मैं एक और अधिक सुरुचिपूर्ण समाधान करना चाहता हूं। – user94154

उत्तर

8

आपको मेरा प्रश्न How Do You Build Your Database From Source Control उपयोगी मिल सकता है।

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

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

  1. एक साझा, सार्वजनिक "पर्यावरण व्हाइटबोर्ड" बनाएँ (यह इलेक्ट्रॉनिक हो सकता है) जहां डेवलपर्स आसानी से देख सकते हैं जो वातावरण उपलब्ध हैं और जो उन्हें इस्तेमाल कर रहा है:

    यहाँ कुछ विचारों को आप पर विचार करने के लिए कर रहे हैं।

  2. डेटाबेस संसाधनों के मालिक होने के लिए किसी व्यक्ति या समूह की पहचान करें। वे वातावरण का ट्रैक रखने और विभिन्न समूहों (डेवलपर्स, परीक्षकों, आदि) की विरोधाभासी आवश्यकताओं को हल करने में मदद करने के लिए जिम्मेदार हैं।
  3. यदि समय और बजट अनुमति देते हैं, तो अपने सभी डेवलपर्स के लिए सैंडबॉक्स वातावरण बनाने पर विचार करें।
  4. यदि आप पहले से ऐसा नहीं करते हैं, तो अपने एकीकरण, परीक्षण और स्वीकृति परीक्षण वातावरण से डेवलपर "प्ले एरिया" को अलग करने पर विचार करें।
  5. सुनिश्चित करें कि आप संस्करण को महत्वपूर्ण डेटाबेस ऑब्जेक्ट्स नियंत्रित करते हैं - विशेष रूप से वे जो अक्सर ट्रिगर्स, संग्रहीत प्रक्रियाओं और विचारों को बदलते हैं। अगर कोई किसी और के बदलाव को ओवरराइट करता है तो आप काम खोना नहीं चाहते हैं।
0

अतीत में, मैंने इस कई तरीकों से निपटाया है।

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

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

0

हमारे पास एक डेटाबेस रखरखाव उपकरण है जिसका उपयोग हम करते हैं जो हमारी टेबल और हमारी प्रोसेस बनाता है/अपडेट करता है। हमारे पास एक सर्वर है जिसमें डेटा के साथ एक अद्यतित डेटाबेस है।

हम स्थानीय डेटाबेस को रखते हैं जिसे हम चुनते समय खेल सकते हैं, लेकिन जब हमें "बेसलाइन" पर वापस जाने की आवश्यकता होती है तो हमें सर्वर से "मास्टर" का बैकअप मिलता है और इसे स्थानीय रूप से पुनर्स्थापित करता है।

अगर हम कॉलम/टेबल/प्रोसेस जोड़ते हैं तो हम डीबीएमन्टेंस उपकरण को अद्यतन करते हैं जो स्रोत नियंत्रण में रखा जाता है।

कभी-कभी, यह दर्द होता है, लेकिन यह उचित रूप से अच्छी तरह से काम करता है।

0

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

विशिष्ट डेटा को शामिल करने के लिए विकास के दौरान उस स्क्रिप्ट को बेहतर बनाएं।

तैनाती से पहले एक स्टेजिंग डेटाबेस पर परीक्षण करें।

हम अंतिम उपयोगकर्ताओं के लिए यूएटी डेटाबेस में उत्पादन डेटाबेस दोहराते हैं। वह डेटाबेस डेवलपर्स द्वारा उपलब्ध नहीं है।

सभी तालिकाओं को छोड़ने में कुछ सेकंड से कम समय लगता है, उन्हें फिर से बनाएं और परीक्षण डेटा इंजेक्ट करें।

यदि आप एक ओआरएम का उपयोग कर रहे हैं जो स्कीमा उत्पन्न करता है, तो आपको सृजन स्क्रिप्ट को बनाए रखने की आवश्यकता नहीं है।

4

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

0

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

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

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

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

0

क्या इस दृष्टिकोण के बारे में:

एक "स्वच्छ db" के लिए एक अलग रेपो बनाए रखें। रेपो तालिका निर्माण/आवेषण आदि के साथ एक एसक्यूएल फाइल होगी।

रेल का उपयोग करना (मुझे यकीन है कि किसी भी गिट रेपो के लिए अनुकूलित किया जा सकता है), एप्लिकेशन के भीतर एक सबमिशन के रूप में "क्लीन डीबी" बनाए रखें। एक स्क्रिप्ट लिखें (रेक कार्य, शायद) जो SQL कथन के साथ स्थानीय देव डीबी से पूछताछ करता है।

अपने स्थानीय डाटाबेस को साफ करने के लिए (और ताजा आंकड़ों के साथ की जगह):

git submodule init 
git submodule update 

तो

rake dev_db:update ......... (or something like that!) 
0

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

  • क्या @tvanfosson सिफारिश के समान, आप SQL स्क्रिप्ट का एक सेट है कि खरोंच से डेटाबेस, या

  • एक अच्छी तरह से परिभाषित, नियमित आधार पर, निर्माण कर सकते हैं डेवलपर डेटाबेस के सभी रखना हम किस प्रकार के डेटा का उपयोग कर रहे हैं, इस पर निर्भर करता है कि उत्पादन डेटा की एक प्रति, या उत्पादन की एक स्केल डाउन/डिडिएंटेड कॉपी के साथ ओवरराइट किया गया है।

2

मैं अनुशंसा करता हूं कि आप इस मामले पर स्कॉट एलन के विचारों पर नज़र डालें। उन्होंने ब्लॉग की एक श्रृंखला लिखी जो मेरी राय में उत्कृष्ट है। Three Rules for Database Work, The Baseline, Change scripts, Views, stored procs etc, Branching and Merging

व्यक्तिगत परिवर्तनों के साथ मैं इन दिशानिर्देशों का अधिक या कम उपयोग करता हूं और वे काम करते हैं।

0

मैं उन सभी एलबुशकिन के साथ सहमत हूं जो उनके जवाब में कहा गया है। यदि आप SQL सर्वर का उपयोग कर रहे हैं, तो हमारे पास Red Gate पर एक समाधान है जो आपको कई विकास वातावरण के बीच आसानी से परिवर्तन साझा करने की अनुमति दे सकता है।

http://www.red-gate.com/products/sql_source_control/index.htm

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

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

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