मैंने इस विषय पर बहुत सोचा और पढ़ा है। यह कॉन्फ़िगरेशन नियंत्रण और परिवर्तन प्रबंधन रणनीति का एक व्यापक विषय है। इस विषय में CMMI का एक डोमेन है। यहां तक कि जिन कंपनियों में सीएमएमआई 3-5 की मान्यता है, वे कभी-कभी अपने डेटाबेस को नियंत्रित नहीं करते हैं।
बाधाओं का ध्यान रखते हुए इस प्रश्न का उत्तर दिया जाना चाहिए ।
- आपके पास एक कीपर है और प्रत्येक डीडीएल को इस कीपर द्वारा निष्पादित किया जाता है।
- अन्य लोगों के पास DDL कथनों को निष्पादित करने की क्षमता है।
- आपको केवल लॉग इन करने की आवश्यकता है जो परिवर्तन किए गए हैं लेकिन आपको विशाल अंतरों की तुलना करने की आवश्यकता नहीं है।
- आपका डेटाबेस डिज़ाइन बाहरी उपकरण के माध्यम से किया जाता है फिर डेटाबेस में प्रकाशित किया जाता है। स्रोत नियंत्रण में भी यह बाहरी उपकरण DDL स्क्रिप्ट हो सकता है। लेकिन मुख्य बिंदु आप स्रोत नियंत्रण है तो डेटाबेस के लिए प्रकाशित करें।
- आपको तात्कालिक परिवर्तनों को जानने की आवश्यकता नहीं है लेकिन समय-समय पर: प्रति घंटा, दैनिक।
- आपके पास एक परिभाषित सर्वर संरचना है: विकास, परीक्षण, उत्पादन। और एक अच्छी परीक्षण रणनीति।
उत्तर 1
- यदि 1, 4,6 सत्य है तो आप बाहरी स्रोत नियंत्रण का उपयोग कर सकते हैं। उदाहरण के लिए
- Embercadero में डेटाबेस चेंज मैनेजमेंट टूल ( http://www.embarcadero.com/products/db-change-manager-xe ) है। जिसमें एक डेटाबेस (ओरेकल) को इंजीनियर रिवर्स करने और अपने स्रोत नियंत्रण में रखने की क्षमता है। फिर कोई भी डेवलपर, dba इस स्कीमा तक पहुंच सकता है और उसमें बदलाव कर सकता है।
- ओरेकल SQL डिज़ाइनर इस दृष्टिकोण के समान है।
- आपको स्रोत नियंत्रण (svn, मर्क्यूरियल आदि) के लिए टेबल स्क्रिप्ट बनाने और उन्हें भी बनाए रखने के लिए एक ही चीज़।
- http://www.liquibase.org ऊपर का स्वचालित तरीका है।
- मैंने कोड जनरेटर लिखा था जो डीएएल (डेटा एक्सेस लेयर), डीडीएल (तालिका बनाएँ) स्टेटमेंट उत्पन्न करता है। हमने उन्हें स्रोत नियंत्रण में रखा और वहां बनाए रखा। मुझे लगता है कि शराबबंदी जैसा समर्पित समाधान बेहतर काम कर सकता है।
यह दृष्टिकोण अच्छी तरह से काम करता है अगर आपके पास 6. आप DDL स्टेटमेंट्स, जो कि एक कोड भी है, सोर्स कंट्रोल में रखें और उसे बनाए रखें। कोई भी बिना सोचे समझे टेस्ट और प्रोडक्शन सर्वर नहीं बदलेगा।
नुकसान यह है कि यदि आप किसी भी कारण से उत्पादन या परीक्षण सर्वर में बदलाव करते हैं, तो एक त्वरित बग फिक्स, प्राथमिक कुंजी परिवर्तन आदि। आपको उस परिवर्तन को विकास सर्वर में भी रोल करने की आवश्यकता है। चूंकि वास्तव में डेवलपमेंट सर्वर आपका ग्राउंड ट्रूथ है। अन्य तरीके से नहीं।
यह एक बहुत ही डेवलपर उन्मुख दृष्टिकोण है। लेकिन जब आप पहली बार एक नया मॉड्यूल विकसित कर रहे हैं तो यह बहुत अच्छी तरह से काम करता है।
उत्तर 2
- यदि 1 और 6 सत्य है:
उत्तर 1 के समान दृष्टिकोण एक विकास सर्वर को बनाए रख रहा है। हर कोई इसे बदल देता है। अद्यतन करने के लिए समय आने पर। आप एक डेटाबेस तुलना उपकरण का उपयोग करते हैं। इन्हें स्क्रिप्ट के रूप में प्राप्त करें, इसे स्रोत नियंत्रण में रखें।
- Red Gate Schema Compare supports Oracle
- Embercadero has similar tool
- https://github.com/carbonfive/db-migration
- http://www.sumsoftsolutions.com/svco/ (I have not used this product but I believe it belongs to this category.)
- Rails Active Migration (http://www.oracle.com/technetwork/articles/kern-rails-migrations-100756.html)
उत्तर 1 और उत्तर 2 के बीच अंतर है, उत्तर 1 में आप पूरे डेटाबेस के लिए डीडीएल स्टेटमेंट एकत्र करते हैं और आप उन्हें स्टोर करते हैं। उत्तर 2 में आपको परिवर्तन के हर संस्करण को संग्रहीत करने की आवश्यकता है।
- प्रारंभ
- V1
- V2
- वी 3
- ...
यदि आप एक मेज पर एक कॉलम रखते हैं और बाद में इसे हटाने का निर्णय लेते हैं। आप लिपियों को उत्तर 2 में दिखाएंगे जबकि उत्तर 1 में आप केवल अंतिम संस्करण देखेंगे। और आपको अंतर देखने के लिए V2 और V1 की तुलना करने की आवश्यकता है। व्यक्तिगत रूप से मुझे उत्तर 1 बेहतर लगता है क्योंकि मैं आसानी से स्टार्ट और वी 3, वी 1 और वी 3 की तुलना कर सकता हूं। उत्तर 2 में, मुझे सभी परिवर्तनों को देखने की आवश्यकता है। स्रोत नियंत्रण में उत्तर 2 स्क्रिप्ट में भी एक बड़ा धमाका होता है, जटिल स्क्रिप्ट। जानकारी पाने के लिए मुश्किल।
उत्तर 3
यदि 3 सत्य है। ध्यान दें कि इस स्थिति में आपके पास बाधा 6 नहीं है, अर्थात: आपके पास विकास, परीक्षण, उत्पाद सर्वर नहीं हैं। केवल उत्पादन सर्वर। जो बदलाव किए गए हैं, उन्हें लॉग करने के लिए आप DDL ट्रिगर्स का उपयोग कर सकते हैं। यह ज्यादातर लोगों को अपने डीडीएल अनुदानों के दुरुपयोग से हतोत्साहित करने के लिए उपयोग किया जाता है। यदि कोई समस्या होती है, तो आप जिम्मेदार पा सकते हैं। इसके लिए काम करने के लिए प्रत्येक व्यक्ति को अपने उपयोगकर्ता खाते से जुड़ना चाहिए और आवेदन खाते में कोई डीडीएल अनुदान नहीं होना चाहिए। चूंकि हर डेवलपर एप्लिकेशन खाता जानता है और उसका उपयोग कर सकता है।
उत्तर 4
यदि आपके पास 3 और 5 है। ध्यान दें कि इस स्थिति में आपके पास 6 बाधाएँ नहीं हैं, अर्थात्: आपके पास विकास, परीक्षण, उत्पाद सर्वर नहीं हैं। केवल उत्पादन सर्वर। परिवर्तन को संग्रहीत करने के लिए ट्रिगर के बजाय। आप स्रोत नियंत्रण में DDL स्क्रिप्ट को संग्रहीत करने और परिवर्तनों को खोजने के लिए एक बाहरी उपकरण का उपयोग करते हैं।
यदि इन उपकरणों में रिकॉर्ड करने की क्षमता है कि किसने बदलाव किए हैं, तो यह उपयोगी होगा। ध्यान दें कि इस समाधान में आप अतिरिक्त डीडीएल को ढीला करते हैं जो अंतराल में किया जाता है।