, डेटाबेस संरचना को अद्यतित कैसे रखें?

Question

यदि आवेदन के बाद आपका डेटा बदल दिया गया है, तो आप डेटाबेस को अद्यतित कैसे रखते हैं?

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

मैं डेटाबेस में मौजूदा डेटाबेस संस्करण के साथ एक टेबल रखना चाहता था। फिर प्रत्येक अपग्रेड एक एसक्यूएल फाइल थी जिसने अपना काम किया - नई टेबल बनाएं, कॉलम जोड़ें या डेटा ले जाएं। फ़ाइलों का नाम उन संस्करणों के नाम पर रखा गया था - इसलिए यदि मेरी अपग्रेड स्क्रिप्ट को डेटाबेस संस्करण 10 मिला, तो उसने अभी तक सभी फ़ाइलों को 11.sql से N.sql तक ले लिया और उनमें से प्रत्येक एक ही समय में डेटाबेस संस्करण संख्या को बढ़ा रहा है।

ऐसा लगता है कि यह ठीक काम कर रहा है, लेकिन मुझे आश्चर्य है - ऐसे कार्यों के लिए आपकी रणनीति क्या है?
अगर मैं एक "पैच" में एक टेबल को सामान्यीकृत करता हूं और इसके बाद मैं इसे किसी भी कारण से फिर से denormalize। फिर यह दो बार किया जाता है।

लेकिन, जब भी मैं कुछ बदलता हूं, एक पूर्ण अपग्रेड स्क्रिप्ट लिखना दर्दनाक और त्रुटि-प्रवण लगता है। कम से कम अधिक परमाणु परिवर्तन।

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

Answer 1

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

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

Answer 2

फ्लाई पर अपनी diff/डेल्टा टी-एसक्यूएल स्क्रिप्ट उत्पन्न करने के लिए xSQL सॉफ़्टवेयर से RedGate's SQLCompare या xSQL ऑब्जेक्ट जैसे टूल का उपयोग करें।

यदि आप चाहें तो इसे अपनी बिल्ड प्रक्रिया के हिस्से के रूप में भी एकीकृत कर सकते हैं।

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

यह संक्षेप में है।

Answer 3

आपको Powerdesigner नामक टूल में देखना चाहिए। आप 15 दिन पूरी तरह परिचालन परीक्षण डाउनलोड कर सकते हैं। यह आपको मॉडल की मदद करेगा, अद्यतित परिवर्तनों को इत्यादि रखेगा,

यह आपके लिए जो कुछ भी पूछ रहा है और बहुत कुछ करने के लिए यह एक शानदार टूल है।

Answer 4

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

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

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

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

Answer 5

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

स्कीमा संशोधन को इंगित करने के लिए, एक कॉलम, एक पंक्ति के साथ अपने डेटाबेस में एक तालिका बनाने में भी मददगार है। माइग्रेशन का समर्थन करने वाले कुछ ढांचे इस बात पर भरोसा करते हैं कि स्कीमा को अपग्रेड या डाउनग्रेड करने के लिए कौन सी माइग्रेशन स्क्रिप्ट लागू होती हैं।

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

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

Answer 6

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

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

यह सब सबवर्सन के तहत संग्रहीत है ताकि जब आवश्यक हो तो मैं वापस रोल कर सकूं। मुझे शायद अपने ऐप के एसवीएन संशोधन और मेरे मॉडल के संशोधन के बीच कुछ प्रकार का लिंक रखना चाहिए।

Answer 7

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

जटिल? कुछ हद तक। जीवन बचाने वाले। abosolutely। ऐप में इरॉस का पीछा करने की तरह कुछ भी नहीं क्योंकि स्कीमा गलत है।

Answer 8

आप शायद aticle कि एटवुड डीबी संस्करण नियंत्रण पर लिखा था हॉरर कोडिंग थोड़ी देर के पीठ पर पढ़ना चाहिए: यहाँ Is Your Database Under Version Control?