जब भी आप डेटाबेस परिवर्तन करते हैं, तो आप इन परिवर्तनों को टीम (और आपके सर्वर) पर अन्य डेटाबेस में कैसे लागू करते हैं?आप अपनी टीम के भीतर एसक्यूएल परिवर्तन कैसे साझा करते हैं?
वर्तमान में हम change.sql नामक फ़ाइल का उपयोग कर रहे हैं जहां हमने अपने सभी परिवर्तनों को आईएसओ दिनांक टिप्पणियों से अलग किया है।
क्या कोई बेहतर तरीका है?
हम आपके दृष्टिकोण के विस्तारित संस्करण का उपयोग करते हैं।
हमारे पास प्रत्येक रिलीज के लिए डेटाबेस अपग्रेड फ़ोल्डर है, जिसमें रिलीज का हिस्सा हैं जो सभी स्क्रिप्ट शामिल हैं। फ़ोल्डर में एक अनुक्रमणिका फ़ाइल है, जिसमें सभी स्क्रिप्ट्स के छद्म लिंक शामिल हैं जिन्हें चलाना चाहिए।
हमारे पास एक क्रूज़ कंट्रोल जॉब है जो वर्तमान उत्पादन डेटाबेस की एक प्रति को पुनर्स्थापित करने के लिए हर रात चलता है, फिर इसके खिलाफ मौजूदा रिलीज की अपग्रेड स्क्रिप्ट चलाता है (इंडेक्स फ़ाइल में परिभाषित स्क्रिप्ट को निष्पादित करके)। एक सीआई नौकरी भी होती है जो किसी भी व्यक्ति को वर्तमान रिलीज के लिए अपग्रेड फ़ोल्डर में कुछ भी जांचता है।
स्क्रिप्ट को स्पष्ट रूप से पुन: चलाने की आवश्यकता है, उदाहरण के लिए उन्हें छोड़ने या इसे बनाने से पहले कुछ के अस्तित्व की जांच करनी चाहिए।
http://dbmaintain.org/overview.html पर एक नज़र डालें - यह डेटाबेस अपडेट प्रबंधित करने के लिए एक बहुत शक्तिशाली टूल है। यह मूल रूप से सही क्रम में कई एसक्यूएल स्क्रिप्ट निष्पादित करके काम करता है। यह याद करता है कि कौन सी स्क्रिप्ट पहले ही निष्पादित की गई थीं। यदि एक निष्पादित स्क्रिप्ट बदल जाती है तो यह या तो एक त्रुटि (उत्पादन मोड में) रिपोर्ट करती है या डेटाबेस को साफ़ करती है और सभी स्क्रिप्ट को फिर से निष्पादित करती है (परीक्षण मोड में)। एक अच्छा ट्यूटोरियल भी है।
संपादित करें: आप एसक्यूएल स्क्रिप्ट को भी समूहित कर सकते हैं (यानी रिलीज द्वारा)। यहां बड़ा लाभ यह है कि आप अपने यूनिट परीक्षण, परीक्षण वातावरण, समेकित एकीकरण, पास-लाइव और उत्पादन वातावरण के लिए एक ही परीक्षण का उपयोग कर सकते हैं।
मेरी वर्तमान नौकरी पर नहीं, लेकिन अतीत में मैंने विजुअल स्टूडियो 2010 में database project का उपयोग किया था, जिसे तब एसवीएन में प्रकाशित किया गया था। हमारे पास विकास से क्यूए, स्टेजिंग और उत्पादन में परिवर्तन को धक्का देने के लिए सॉफ़्टवेयर स्वचालन के बजाय एक एसओपी था।
जिस टीम के साथ मैंने काम किया वह डीबी डिजाइन और .NET विकास के लिए साझा जिम्मेदारी के साथ पांच-पांच डेवलपर्स था।
आपको अपने डेटाबेस पर संस्करण नियंत्रण का उपयोग करने पर भी विचार करना चाहिए। एक उदाहरण Liquibase है। संस्करण नियंत्रण का उपयोग करके आप तालिका संरचना में सभी परिवर्तनों पर टिप्पणी कर सकते हैं, इस प्रकार आपको एक परिवर्तन.sql फ़ाइल की आवश्यकता नहीं है।
हम एक माइग्रेशन टूल (migratordotnet - अन्य विकल्प मौजूद हैं) का उपयोग करते हैं जो आपको सी # कक्षाएं लिखने देता है जो डेटाबेस कमांड निष्पादित करता है। माइग्रेशन प्रोग्राम के प्रत्येक आमंत्रण या एकीकरण परीक्षणों, और प्रत्येक परिनियोजन पर सर्वर पर स्थानीय रूप से चलते हैं। माइग्रेशन फ्रेमवर्क स्वचालित रूप से ट्रैक करता है कि किस माइग्रेशन लागू किए गए हैं। बेशक, माइग्रेशन संस्करण नियंत्रण भंडार का हिस्सा हैं।
तो, यदि परिवर्तन फ़ाइल में शामिल है और INSERT INTO, तो क्या आप पहले इसके अस्तित्व की जांच करते हैं? चुनें ... कहाँ? अगर जांच करने के लिए कोई पहचानकर्ता नहीं है तो क्या होगा? – Tower
मुझे लगता है कि यह वास्तव में निर्भर करता है कि आप क्या डाल रहे हैं, और इसे दो बार डालने के क्या परिणाम हैं। क्या यह एक अद्वितीय इंडेक्स बाधा के कारण असफल हो जाएगा, या यह अंदर जाएगा, और यदि ऐसा है, तो क्या यह खराब डेटा बनाएगा? हम स्थिरता सुनिश्चित करना चाहते हैं, इसलिए हमारे आवेषण आमतौर पर IF [NOT] EXISTS द्वारा लिपटे होते हैं (x से चुनें 1 ...)।कभी-कभी WHERE क्लॉज में मिलान करने के लिए दो फ़ील्ड होंगे - यदि आप कुछ डालने वाले हैं, तो आपको पता होना चाहिए कि वे क्या हैं और अधिकांश इकाइयों में प्राकृतिक प्रकार की प्राकृतिक कुंजी होगी। –