एक छोटी कंपनी के लिए सरल तरीका:अपने डेटाबेस को SQL में डंप करें और इसे अपने रिपॉजिटरी में जोड़ें। फिर हर बार जब आप कुछ बदलते हैं, तो डंप फ़ाइल में बदलाव जोड़ें।
फिर आप संस्करणों के बीच परिवर्तन देखने के लिए diff का उपयोग कर सकते हैं, उल्लेख नहीं करने के लिए टिप्पणियों में आपके परिवर्तनों को समझाते हैं। यह आपको MySQL अपग्रेड के प्रति लगभग प्रतिरक्षित भी बना देगा।
मैंने इसे देखा है कि एक नकारात्मक पक्ष यह है कि आपको अपने डंपफाइल में मैन्युअल रूप से एसक्यूएल जोड़ना याद रखना होगा। आप हमेशा याद रखने के लिए खुद को प्रशिक्षित कर सकते हैं, लेकिन अगर आप दूसरों के साथ काम करते हैं तो सावधान रहें। अपडेट मिस करना बाद में परेशानी का सबब बन सकता है।
सबवर्सन के लिए सबमिट करते समय इसे आपके लिए करने के लिए कुछ विस्तृत स्क्रिप्ट बनाकर इसे कम किया जा सकता है लेकिन यह वन मैन शो के लिए थोड़ा अधिक है।
संपादित करें: इस उत्तर के बाद से उस वर्ष में, मुझे एक छोटी टीम के लिए MySQL के लिए एक संस्करण योजना लागू करनी पड़ी। प्रत्येक परिवर्तन को मैन्युअल रूप से जोड़ना एक बोझिल समाधान के रूप में देखा गया था, जैसा कि टिप्पणियों में उल्लेख किया गया था, इसलिए हम डेटाबेस को डंप करने और उस फ़ाइल को संस्करण नियंत्रण में जोड़ने के साथ गए।
हमने जो पाया वह यह था कि परीक्षण डेटा डंप में समाप्त हो रहा था और यह पता लगाना काफी मुश्किल था कि क्या बदल गया था। इसे केवल स्कीमा को डंप करके हल किया जा सकता है, लेकिन हमारी परियोजनाओं के लिए यह असंभव था क्योंकि हमारे एप्लिकेशन डेटाबेस में कुछ डेटा पर कार्य करने के लिए निर्भर थे। अंततः हम डेटाबेस डंप में मैन्युअल रूप से परिवर्तन जोड़ने पर लौट आए।
यह न केवल सबसे सरल समाधान था, बल्कि इसने कुछ मुद्दों को भी हल किया जो MySQL के कुछ संस्करणों में निर्यात/आयात के साथ हैं। आम तौर पर हमें विकास डेटाबेस को डंप करना होगा, किसी भी परीक्षण डेटा को हटाना होगा, प्रविष्टियों को लॉग करना होगा, आदि, जहां लागू हो वहां कुछ नामों को हटाना/बदलना होगा और उसके बाद ही उत्पादन डेटाबेस बनाने में सक्षम होंगे। मैन्युअल रूप से परिवर्तनों को जोड़कर हम उत्पादन में क्या होगा, इसे एक बार में थोड़ा-थोड़ा नियंत्रित कर सकते हैं, ताकि अंत में सब कुछ तैयार हो और उत्पादन वातावरण में जाना जितना संभव हो उतना दर्द रहित हो।
