डेटाबेस संरचना का संस्करण विस्थापित: सिद्धांत से अभ्यास करने के लिए

विषय डेटाबेस संरचना के संस्करण के लिए एक और सरल प्रणाली पर विचार करता है, साथ ही साथ आईएमएचओ, अन्य हमें क्यों सूट नहीं करते हैं।


डेटाबेस संरचना के हब्रेडर शेडल संस्करणित प्रवास के विषय पर गलती से ठोकर खाई : मूल दृष्टिकोण । मैं एक विस्तृत टिप्पणी लिखना चाहता था, लेकिन बाद के निर्माण की तारीख को देखा और एक अलग विषय जारी करने का फैसला किया।

इस विषय का उद्देश्य डेटाबेस के संस्करण के दृष्टिकोण की समीक्षा करना नहीं है - यह ऊपर दिए गए लिंक पर लेख में उल्लेखनीय रूप से किया गया है - केवल दृष्टिकोण पर एक संक्षिप्त IMHO होगा जो किसी कारण से हमारे लिए उपयुक्त नहीं था।

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

समस्या का बयान

हम कोहाना फ्रेमवर्क का उपयोग करके PHP + MySQL में विकसित कर रहे हैं। यह किसी भी तरह डेटाबेस संरचना प्रवासन की प्रक्रिया को व्यवस्थित करने के लिए आवश्यक था ताकि किसी भी तरह टेस्ट सर्वर और उत्पादन के लिए तैनाती को स्वचालित किया जा सके। हम साधारण व्यवसाय कार्ड साइट नहीं लिखते हैं, बल्कि सुपर-कॉम्प्लेक्स परियोजनाएं भी लिखते हैं। अधिकांश भाग के लिए मुख्य परियोजनाएं बहुत बड़ी नहीं हैं (डेटाबेस में 15-30 टेबल; 50-200 आदमी घंटे)। नीचे लिखा सब कुछ हमारे लिए सच है, लेकिन यह बहुत संभव है कि यह अधिक जटिल परियोजनाओं या अन्य प्रौद्योगिकियों / रूपरेखाओं में फिट नहीं होगा (कई रूपरेखाओं में डेटाबेस माइग्रेशन का अपना कार्यान्वयन है, इसलिए निश्चित रूप से अन्य बाइक का उपयोग करने का कोई मतलब नहीं है)

डेटाबेस की संरचना की स्रोत कोड से तुलना करने की विधि

जब पूरे डेटाबेस स्कीमा को संस्करण नियंत्रण प्रणाली में संग्रहीत किया जाता है, और डेटाबेस को नवीनतम संस्करण में स्थानांतरित करने के लिए, एक अलग स्क्रिप्ट उत्पन्न होती है जो मूल डेटाबेस को अंतिम में परिवर्तित करती है। सिद्धांत रूप में, सब कुछ ठीक है, व्यवहार में समस्याएं हैं:

• मौजूदा उपकरण हमेशा (यहां तक ​​कि सैद्धांतिक रूप से) इस समस्या को स्वचालित रूप से हल नहीं कर सकते हैं। सबसे सरल उदाहरण एक स्तंभ या तालिका का नाम बदल रहा है।
• मैं व्यक्तिगत रूप से उत्पादन के लिए ALTER स्क्रिप्ट बनाने के कार्यक्रम पर कभी भरोसा नहीं करूंगा, जिसका अर्थ है कि उनका उपयोग करने से पहले आपको उन्हें अपने हाथों से देखने / संपादित करने की आवश्यकता है

हमने कई उपकरण आज़माए और इस विकल्प को छोड़ दिया।

वृद्धिशील परिवर्तन विधि

कई विकल्प हैं: या तो हम मैन्युअल रूप से लिखी गई स्क्रिप्टों को संग्रहीत करते हैं, या हम उन्हें PHP में लिखते हैं (या कोई अन्य जिसका उपयोग हम अपने आवेदन को लिखने के लिए करते हैं)। निर्वात में ऐसे गोलाकार प्रवास का एक उदाहरण:

class Migration_0001 extends Migration_Abstract { public function up() { $this->createTable("users") ->column("id", self::PK) ->column("username", self::VARCHAR); } public function down() { $this->dropTable("users"); } } 

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

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

हमारा निर्णय

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

सभी डेटाबेस परिवर्तन अलग .sql फ़ाइलों में संग्रहीत किए जाते हैं (हम, जैसे कई, उन्हें डेल्टास कहते हैं) एक फ़ोल्डर में। वर्णमाला के क्रम में परिवर्तन होते हैं। लागू डेल्टास को चैंज प्लेट में संग्रहीत किया जाता है (जो एक अलग "प्रारंभिक" एसक्यूएल डंप से लोड होता है)। माइग्रेट करते समय, सभी अप्रयुक्त डेल्टा लागू होते हैं। वह सब है। डेल्टास के साथ एक फ़ोल्डर का एक उदाहरण:
deltas
|- 0001-users.sql
|- 0002-users-add-username.sql
'- 0003-users-drop-last-login.sql

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

डेल्टा लिपियों की एंड-टू-एंड नंबरिंग के लिए एक नियम का अभाव चमत्कारिक रूप से इस दृष्टिकोण की मुख्य समस्या को हल करता है - रिपॉजिटरी की विभिन्न शाखाओं में समानांतर विकास। मैं समझा दूंगा।

मान लीजिए कि हमारे पास एक ट्रंक में तीन डेल्टा हैं - जैसा कि ऊपर वर्णित है। उदाहरण के लिए, वासिका एक ब्रंच बनाती है, चेकबॉक्स को "मुझे याद रखें" को जोड़ने के लिए, पेट्या इस समय ट्रंक में छोटे कीड़े को सही करना जारी रखता है। Vasya डेल्टा 0004-user-tokens.sql जोड़ता है, पेट्या deltas 0004-user-change -username-length.sql और 0005-users-add-email.sql जोड़ता है । ठीक है। मर्ज के बाद, "नंबर" 0004 के तहत ट्रंक में दो डेल्टास होंगे - लेकिन नंबर हमारे लिए महत्वपूर्ण नहीं है, हम सभी अप्रयुक्त लागू करते हैं, इसलिए वासना के परिवर्तनों को पेटीएम के ट्रंक में बिना किसी समस्या के आधार पर लागू किया जाएगा।

बेशक, तालिका के समान कॉलम को बदलते समय टकराव हो सकता है, लेकिन यह स्थिति अत्यंत दुर्लभ है।