2009-09-23 11 views
6

यहां एक सामान्य सवाल है कि आप विकास टीम में डेटाबेस स्कीमा परिवर्तनों को कैसे प्रबंधित करते हैं।एक देव टीम में डेटाबेस स्कीमा परिवर्तन से निपटने के लिए आपकी प्रक्रिया क्या है?

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

जब भी हम में से कोई निर्णय लेता है कि यह डीबी स्कीमा को विस्तार/बदलने का समय है, तो हम डेटाबेस फ़ाइलों (MYI/MYD) या SQL फ़ाइलों को चारों ओर निष्पादित करने के लिए मेल करते हैं, या फ़ोन पर अन्य निर्देश देते हैं कि उन्हें क्या करना है अपने स्थानीय डीबी पर चल रहे कोड को प्राप्त करें। यह निश्चित रूप से सही दृष्टिकोण नहीं है। एक ही समस्या तब उत्पन्न होती है जब हमें नई रिलीज तैयार होने के बाद स्टेजिंग या उत्पादन पर डीबी स्कीमा को समायोजित करने की आवश्यकता होती है।

मैं सोच रहा था ... आप इस तरह की चीजें कैसे संभालेंगे? स्रोत कोड के लिए, हम एसवीएन का उपयोग करते हैं।

वास्तव में आपके इनपुट की सराहना करते हैं!

धन्यवाद, माइकल

+1

प्रश्न दोहराएं? http://stackoverflow.com/questions/778317/need-a-better-way-to-manage-database-chechema-changes –

उत्तर

8

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

+0

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

+0

हम यह भी करते हैं (हालांकि हम एसवीएन के बजाय टीएफएस का उपयोग करते हैं)। मुझे संस्करण नियंत्रण में लिपियों को संग्रहित करना अच्छा लगता है, क्योंकि अब आप परिवर्तनों के इतिहास को ट्रैक कर सकते हैं! शाखा या एक लेबल को डीबी स्क्रिप्ट के एक विशेष सेट के साथ लेबल जोड़ने से बेहतर है। – Joshua

2

कम से कम आप डेटाबेस (टेबल, संग्रहित प्रक्रियाओं, आदि) स्रोत नियंत्रण में में सभी वस्तुओं की स्क्रिप्ट होना चाहिए।

मुझे नहीं लगता कि मेलिंग स्कीमा परिवर्तन पेशेवर विकास टीम के लिए एक वास्तविक विकल्प है।

1

हमारे पास मेरी पिछली टीमों में से एक प्रणाली थी जो इस स्थिति से निपटने के लिए सबसे अच्छा था।

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

इसने मास्टर कॉपी को एक स्थान पर रखा और डेवलपर्स पर अपने स्थानीय देव डेटाबेस को ताजा रखने के लिए रख दिया।

0

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

  1. डेटाबेस स्कीमा उन्नयन और उचित रूप से किसी भी मौजूदा डेटा को संशोधित करेगा, और
  2. डेटाबेस में संस्करण संख्या अद्यतन करेगा।

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

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

0

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

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

0

मैं निश्चित रूप से डेटाबेस कोड नियंत्रण में डेटाबेस स्कीमा रखूंगा।

मेरे वर्तमान काम पर, हर बार एक स्कीमा परिवर्तन होता है, हम परिवर्तन के लिए एसक्यूएल लिखते हैं (तालिका xyz जोड़ें कॉलम ...) और इसे एसवीएन में डाल दें। फिर डेवलपर इस स्क्रिप्ट को चलाकर परीक्षण डेटाबेस अपडेट कर सकते हैं। यह बहुत बेकार है लेकिन यह काम करता है।

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

मुझे लगता है कि ऐसा करने के लिए कुछ सामान्य SQL उपकरण होना चाहिए। शायद वहाँ है, लेकिन मैंने कभी नहीं देखा है।

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