डेटाबेस स्रोत नियंत्रण

Question

क्या डेटाबेस फाइलें (स्क्रिप्ट आदि) सोर्स कंट्रोल पर होनी चाहिए? यदि हां, तो इसे रखने और इसे अपडेट करने का सबसे अच्छा तरीका क्या है?

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

स्रोत-नियंत्रण पर डेटाबेस के लिए किस दृष्टिकोण का सबसे अच्छा उपयोग किया जाता है?

Comments

एक हजार बार हाँ! सरल प्रश्न एक सरल उत्तर के हकदार हैं।

— maple_shaft

क्या इस विषय पर एक बार बहुत बड़ी चर्चा नहीं हुई थी, stackoverflow.com पर?

— FrustratedWithFormsDesigner 14

डेटाबेस SQL ​​फ़ाइलें (ddl, dml) कोड हैं। सभी कोड एक संस्करण नियंत्रण प्रणाली में होना चाहिए।

— डायटबुद्ध

अहा! मुझे लगता है कि यह वही है जो मैं देख रहा था: stackoverflow.com/questions/115369/…

— FrustratedWithFormsDesigner

न केवल आपके डेटाबेस को स्रोत नियंत्रण में होना चाहिए, बल्कि एक एकल स्क्रिप्ट होनी चाहिए जिसे आप इसे खरोंच से फिर से बनाने के लिए चला सकते हैं, वह टेबल, अनुक्रम, दृश्य, पैकेज आदि हैं

— बेन

Answer 1

हाँ। आपको डेटाबेस सहित स्रोत नियंत्रण से अपने सिस्टम के किसी भी हिस्से का पुनर्निर्माण करने में सक्षम होना चाहिए (और मैं कुछ स्थिर डेटा का भी तर्क दूंगा)।

यह मानते हुए कि आप इसे करने के लिए एक उपकरण नहीं चाहते हैं, मेरा सुझाव है कि आप निम्नलिखित शामिल करना चाहते हैं:

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

सभी लिपियों में उपयुक्त ड्रॉप स्टेटमेंट शामिल होने चाहिए और उन्हें लिखा जाना चाहिए ताकि उन्हें किसी भी उपयोगकर्ता के रूप में चलाया जा सके (इसलिए प्रासंगिक रूप से संबंधित स्कीमा / मालिक उपसर्ग सहित)।

अपडेट / टैगिंग / ब्रांचिंग की प्रक्रिया बाकी स्रोत कोड की तरह ही होनी चाहिए - यदि आप किसी एप्लिकेशन संस्करण के साथ डेटाबेस संस्करण को संबद्ध नहीं कर सकते हैं, तो ऐसा करने का कोई मतलब नहीं है।

संयोग से, जब आप कहते हैं कि लोग केवल परीक्षण सर्वर को अपडेट कर सकते हैं, तो मुझे उम्मीद है कि आप विकास सर्वर का मतलब है। यदि डेवलपर्स मक्खी पर परीक्षण सर्वर को अपडेट कर रहे हैं तो आप दर्द की दुनिया को देख रहे हैं जब यह काम करने की बात आती है जिसे आपको जारी करने की आवश्यकता है।

Comments

क्या कोई उपकरण है जो डेटाबेस कॉन्फ़िगरेशन के एसपीएम को स्वचालित करता है एसपी गुण को संस्करण नियंत्रण के बिना मैन्युअल रूप से करने के लिए!

— अली

@ अलि: सपाट को एक फ्लैटफाइल में लिखें जो संस्करण नियंत्रित है। क्या वह db स्क्रिप्ट में इनपुट है जो आपके माइग्रेशन को चलाता है।

— आहारबुद्ध

Answer 2

हाँ।

इसे रखने और इसे अपडेट करने का सबसे अच्छा तरीका क्या है?

उम। एक स्कीमा-बिल्डर स्क्रिप्ट लिखें। बदलाव करने के बाद इसकी जांच करें। इसे चलाने से पहले इसे देखें।

यह निर्धारित करना कठिन है कि आप क्या पूछ रहे हैं।

औपचारिक स्कीमा माइग्रेशन स्क्रिप्ट लिखें। परीक्षण के बाद उन्हें जांचें। उन्हें चलाने से पहले बाहर की जाँच करें।

और क्या है?

ऐसा होता है कि स्कीमा परिवर्तन गंभीर समस्याओं में बदल जाता है क्योंकि स्कीमा अनैजेंटेड परिवर्तनों की एक श्रृंखला के माध्यम से व्यवस्थित रूप से विकसित होता है।

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

यदि कोई एकल, आधिकारिक स्रोत था, तो स्कीमा माइग्रेशन पिछले संस्करण और इस संस्करण के बीच का डेल्टा है।

Answer 3

हाँ

डेटाबेस स्क्रिप्ट (ddl, dml) कोड हैं। सभी कोड एक संस्करण नियंत्रण प्रणाली में होना चाहिए।

माइग्रेशन

• डेटाबेस माइग्रेशन का उपयोग करें

आपको विकास, qa और रिलीज़ में समान db फ़ाइलों का उपयोग करने की अनुमति देता है।

• एक रिलीज़ नंबर के साथ डेटाबेस को रिलीज़ करें

ऑडिटिंग के लिए रिलीज़ नंबर को कहीं स्टोर करें, कई इसे डीबी में ही स्टोर करें। प्रत्येक रिलीज़ माइग्रेशन से बना होगा जो डेटाबेस को सही संस्करण तक लाएगा।

Answer 4

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

हमने डेटाबेस तुलना टूल (मास्टर बनाम ग्राहक डीबी की तुलना) के साथ इसे स्वचालित करने की भी कोशिश की है और इससे मदद मिली है, लेकिन आप ऐसे उपकरणों पर 100% भरोसा नहीं कर सकते हैं, आपको निश्चित रूप से एक समीक्षा प्रक्रिया की भी आवश्यकता है।

Comments

मैंने सिर्फ इस लिकिबेस टूल में देखा, जो आपने बताया है। दिलचस्प लगता है। यह SQL सर्वर डेटाबेस के साथ कैसे काम करता है? क्या आपको कोई अनुभव था?

— TheBoyan

@bojanskr: मुझे डर है कि मेरे पास कोई अनुभव नहीं है लेकिन वेबसाइट SQL सर्वर को "कोई समस्या नहीं" के साथ सूचीबद्ध करती है।

— फाल्कन

वैसे भी टिप के लिए धन्यवाद। आपकी सलाह बहुत मददगार रही है।

— 18

Answer 5

हाँ

और फुर्सत में, आपको शाखाएँ चाहिए ।

---

मैं शाखाओं के लिए Git का उपयोग करता हूं:

• प्रति-सुविधा के विकास के लिए (जैसे हम बाकी एप्लिकेशन के नियमित विकास के लिए करते हैं)

• और उत्पादन सर्वर के लिए भी एक क्योंकि अनुप्रयोग का उपयोग करने वाले ग्राहक सामग्री भी बनाते हैं।

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

---

मुझे अब तक [पोस्टग्रेक्यूएल के लिए] एक ऑल-इन-वन सिस्टम नहीं मिला है, इसलिए मुझे शाखाओं को मर्ज करते समय ठीक से रींडैक्स करने के लिए फ़ंक्शन / स्क्रिप्ट लिखना पड़ता था (उदाहरण के लिए उत्पादन शाखा से किसी भी सूचकांक को संशोधित नहीं किया जाना चाहिए क्योंकि ग्राहक उन पर भरोसा करते हैं जबकि विकास की शाखा से अनुक्रमित + विदेशी कुंजी जो उत्पादन सामग्री के साथ प्रतिच्छेद करती है: इसे सभी अनुप्रयोगों के लिए काम नहीं करना चाहिए, लेकिन यह हमारे आवेदन के सभी मामलों को कवर करता है, इसलिए यह काफी अच्छा है)।

लेकिन सामान्य विचार यह है कि डेटाबेस सामग्री अनुप्रयोग का एक अनिवार्य हिस्सा है, और सभी पुनरावृत्ति स्रोत नियंत्रण में होनी चाहिए , हाँ, आपको डेटाबेस के लिए भी स्रोत नियंत्रण का उपयोग करना चाहिए।

Answer 6

जावा के लिए, हमारी टीम फ्लाईवे का उपयोग करती है , जो हमें वास्तव में उपयोग करने में आसान और शक्तिशाली लगता है।

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

लिकिबेस पहले ही उल्लेख किया जा चुका है - यह एक अच्छा समाधान है लेकिन मैंने इसे फ्लाईवे जैसे विकल्पों की तुलना में अधिक बोझिल पाया।

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

Answer 7

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

डेटाबेस संस्करण नियंत्रण को प्रभावी होने के लिए नियमित कोड संस्करण नियंत्रण के समान नहीं होना चाहिए। हालांकि, कुछ प्रकार के परिवर्तन नियंत्रण और इतिहास बैकअप कई समस्याओं को रोकेंगे।

Comments

आपको इस लेख में दिलचस्पी हो सकती है: martinfowler.com/articles/evodb.html

— फाल्कन

Answer 8

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

Answer 9

हमारे PHP / MySQL प्रोजेक्ट्स के लिए, हम लैडर नामक एक (एक बार) छोटे टूल का उपयोग कर रहे हैं । यह समय के साथ एक डेटाबेस के जैविक विकास को सुविधाजनक बनाने के लिए डिज़ाइन किया गया है। किसी परियोजना के लिए सभी माइग्रेशन संशोधन / स्रोत / संस्करण नियंत्रण में संग्रहीत किए जाते हैं, और कोड के साथ ट्रैक किए जाते हैं।

यह स्तंभों को जोड़ने / बदलने / छोड़ने, प्रश्नों को चलाने, अनुक्रमणिका, अवरोधों आदि को जोड़ने, आदि का समर्थन करता है। यह उस डेटाबेस का पता लगाने की स्थिति को बनाए रखेगा जो किसी भी लापता पलायन को लागू करता है। यह आपको एक प्रवास निर्दिष्ट करके "समय में कदम पीछे" करने की अनुमति देता है जो आपको होना चाहिए। ( php ladder.php migrate 15)

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

Answer 10

DataGrove यहाँ वर्णित कुछ समस्याओं को हल करता है ( उदाहरण के लिए, jfrankcarr द्वारा )।

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

Answer 11

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

लेकिन आगे जाने से पहले मैं उद्धृत करूँगा कि संस्करण बनाने के लिए पूरे डेटाबेस को रखना उचित नहीं होगा। डेटा के एक विशेष सेट के लिए परिवर्तन को ट्रैक करना वास्तविक हत्यारा है।

मोनयोग में CSO (कस्टम SQL ऑब्जेक्ट) नामक एक सुविधा है , जो डेटा के विशेष सेट में परिवर्तन की निगरानी कर सकता है। CSO जोड़ने का वर्णन यहाँ किया गया है । अब मोनयोग के मॉनिटर हिस्ट्री सेक्शन में आपको समय के साथ बदलाव मिल सकते हैं। सबसे अच्छा, यह html पृष्ठ में एक दृश्य रिपोर्ट देता है। रिपोर्ट कुछ इस तरह दिखाई देगी