मार्टिन फाउलर ने इस विषय पर मेरा पसंदीदा लेख http://martinfowler.com/articles/evodb.html लिखा। मैं स्कीमा डंप को संस्करण नियंत्रण में अलंब . के रूप में नहीं रखना चुनता हूं और अन्य सुझाव देते हैं क्योंकि मुझे अपने उत्पादन डेटाबेस को अपग्रेड करने का एक आसान तरीका चाहिए।
एक वेब एप्लिकेशन के लिए जहां मेरे पास एक एकल उत्पादन डेटाबेस इंस्टेंस होगा, मैं दो तकनीकों का उपयोग करता हूं:
डेटाबेस अपग्रेड स्क्रिप्ट
एक अनुक्रम डेटाबेस अपग्रेड स्क्रिप्ट जिसमें स्कीमा को संस्करण N से N+1 में स्थानांतरित करने के लिए आवश्यक DDL होता है। (ये आपके संस्करण नियंत्रण प्रणाली में जाते हैं।) एक _version_history_ तालिका, कुछ इस तरह
create table VersionHistory (
Version int primary key,
UpgradeStart datetime not null,
UpgradeEnd datetime
);
हर बार अपग्रेड स्क्रिप्ट चलने पर एक नई प्रविष्टि मिलती है जो नए संस्करण से मेल खाती है।
यह सुनिश्चित करता है कि यह देखना आसान है कि डेटाबेस स्कीमा का कौन सा संस्करण मौजूद है और डेटाबेस अपग्रेड स्क्रिप्ट केवल एक बार चलती है। दोबारा, ये नहीं हैं डेटाबेस डंप। बल्कि, प्रत्येक स्क्रिप्ट परिवर्तन . का प्रतिनिधित्व करती है एक संस्करण से दूसरे संस्करण में जाने के लिए आवश्यक है। वे स्क्रिप्ट हैं जिन्हें आप अपने उत्पादन डेटाबेस पर "अपग्रेड" करने के लिए लागू करते हैं।
डेवलपर सैंडबॉक्स सिंक्रोनाइज़ेशन
- उत्पादन डेटाबेस के बैकअप, सैनिटाइज़ और सिकोड़ने के लिए एक स्क्रिप्ट। उत्पादन डीबी में प्रत्येक अपग्रेड के बाद इसे चलाएं।
- डेवलपर के वर्कस्टेशन पर बैकअप को पुनर्स्थापित करने के लिए एक स्क्रिप्ट (और यदि आवश्यक हो तो ट्वीक करें)। प्रत्येक डेवलपर इस स्क्रिप्ट को प्रोडक्शन डीबी में अपग्रेड करने के बाद चलाता है।
एक चेतावनी:मेरे स्वचालित परीक्षण एक स्कीमा-सही लेकिन खाली डेटाबेस के विरुद्ध चलते हैं, इसलिए यह सलाह पूरी तरह से आपकी आवश्यकताओं के अनुरूप नहीं होगी।
