नए वर्जन को पुश करने पर डेटाबेस स्कीमा में बदलाव होता है

Question

भारी विकास के समय के दौरान, डेटाबेस स्कीमा तेजी से और लगातार दोनों को बदलता है, और जब तक बीटा निर्माण के लिए हमारा साप्ताहिक धक्का चारों ओर आता है, तब तक स्कीमा इतना बदल गया है कि एकमात्र समझदार विकल्प मैं सभी तालिकाओं को उल्टा कर सकता हूं। मेरे देव डेटाबेस से नए संस्करणों की प्रतिलिपि बनाएँ। जाहिर है, यह एक बार हम लॉन्च करने के लिए काम नहीं कर रहा है, क्योंकि उत्पादन डेटा को nuking करना आपदा के लिए एक नुस्खा है, इसलिए मैं सोच रहा था कि डेटाबेस स्कीमा परिवर्तन को एक संस्करण / संशोधन से दूसरे में प्रबंधित करने के लिए क्या रणनीति थी?

कुछ मैंने पाया या अनुभव किया है:

1. एक डेटाबेस से दूसरे में सीधे nuke और डंप (अब मैं क्या कर रहा हूं)
2. SQL स्टेटमेंट के साथ एक UPDATE.sql फ़ाइल बनाए रखना जो स्क्रिप्ट या हाथ से चलाया जाता है।
3. सक्रिय डेटाबेस में एक संबंधित "डीबी-स्कीमा-संस्करण" मूल्य के साथ एक अपडेट। एफपी फ़ाइल बनाए रखना

तीसरा विकल्प सबसे समझदार लगता है, लेकिन अभी भी एक बुरी तरह से निर्मित SQL क्वेरी के मध्य-स्क्रिप्ट में विफल होने की संभावना मौजूद है, डेटाबेस को आधे-अद्यतन स्थिति में छोड़कर बैकअप की बहाली की आवश्यकता होती है।

यह एक गैर-मुद्दे की तरह लगता है, लेकिन ऐसा होता है, जब से हम एक टीम के रूप में, हम phpMyAdmin का उपयोग करते हैं, और मैं अपने आप पर भी भरोसा नहीं कर सकता कि याद रखें कि मार डाला एसक्यूएल बयान को अपडेट.फैप फ़ाइल में पेस्ट करने के लिए। एक बार जब आप किसी अन्य पृष्ठ पर जाते हैं, तो मुझे हाथ से SQL कथन को फिर से लिखना होगा, या अपने परिवर्तन को उल्टा करना होगा और फिर से करना होगा।

मुझे लगता है कि मैं जो उम्मीद कर रहा हूं वह एक समाधान है जो हमारे स्थापित विकास वर्कफ़्लो को प्रभावित नहीं करता है?

Comments

लेकिन निश्चित रूप से, आप इसे सक्रिय डेटाबेस पर लागू करने से पहले अपनी update.phpया update.sqlफ़ाइल का परीक्षण वातावरण में परीक्षण करेंगे, है ना? और PHPMyAdmin को संभावित समस्याओं के लिए दोषी ठहराया जा रहा है जो स्क्रिप्ट जैसे हो सकते हैं, शायद यह एक अलग या बेहतर उपकरण देखने का समय है?

— FrustratedWithFormsDesigner

हाहा, हाँ, तुमने मुझे पकड़ लिया। मैं पहली बार उन्हें हल करने के बजाय अपनी खुद की विफलताओं के आसपास काम करने की कोशिश कर रहा हूं।

— जूलियन एच। लैम

यदि आपको यह काम मिला है तो कृपया एक उदाहरण स्क्रिप्ट दिखाएंगे? मैं यह भी करने की कोशिश कर रहा हूं, लेकिन मैं MS Sql के बीच किसी भी MySql का अनुवाद कैसे नहीं कर सकता: stackoverflow.com/questions/26948916/…

— रिचर्ड

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

— इते मूव -मालिमोवका

Answer 1

स्वचालित। स्वचालित। स्वचालित।

आप एक स्पष्ट DB संस्करण संख्या के साथ सही रास्ते पर हैं, लेकिन मैं एक कदम और आगे जाऊंगा और कोड को स्पष्ट रूप से जानूंगा कि यह किस स्कीमा के खिलाफ काम करने की उम्मीद करता है (जैसे वास्तविक DDL स्क्रिप्ट को कम करके और अपडेटर पार्स होने से ); इसके बाद अपडेट समय पर आपको केवल मौजूदा मेटाडेटा और INSERT / DROP / ALTER के माध्यम से मौजूदा योजना की खोज करनी है, इससे कोई फर्क नहीं पड़ता कि आप किस संस्करण से अपडेट कर रहे हैं। (आप डेटाबेस में एक स्पष्ट संस्करण संख्या भी रख सकते हैं और इंस्टॉलर के साथ पूरे स्कीमा इतिहास को वितरित कर सकते हैं ताकि आप स्कीमा खोज भी न कर सकें।)

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

Comments

महान सलाह Kilian, धन्यवाद। मैं अंततः इसे स्वचालित करने की उम्मीद कर रहा था, लेकिन कुछ बिंदु पर, यह लगता है कि मानव भागीदारी अभी भी अपडेट / अलर्ट बयान उत्पन्न करने के लिए आवश्यक है।

— जूलियन एच। लैम

Answer 2

डेटाबेस स्कीमा संस्करणिंग जाने का तरीका है - प्रत्येक संस्करण में डेटाबेस में केवल एक परिवर्तन होता है, या कम से कम ऐसे परिवर्तन होते हैं जिन्हें संपूर्ण रूप में बदला जा सकता है। DBDeploy एक स्वचालित उपकरण है जो स्वचालित है।

कुछ चीजें जो मैंने सीखी हैं वे उपयोगी हैं:

1. हमेशा अपने परिवर्तन का स्थानीय रूप से परीक्षण करें, और इसके साथ अपने कोड का परीक्षण करें, बस ALTERपासिंग पर्याप्त नहीं है
2. आपको सिंक्रनाइज़ करने की आवश्यकता है जो पहले अपना परिवर्तन करते हैं - एक साधारण विकी पृष्ठ जहां आप मेरी टीम के लिए "महान संख्या" ले सकते हैं।
3. टूटे हुए परिवर्तन को ठीक करने की कोशिश न करें, इसे नकारने के लिए एक नया प्रति-परिवर्तन जोड़ें, यह बहुत दर्द रहित है
4. आपका कोड उस परिवर्तनों पर निर्भर करता है - अपने बग-ट्रैकिंग सिस्टम के मुद्दों को DB परिवर्तनों से जोड़ना सुनिश्चित करें। जो कि तैनाती के समय बहुत मददगार है।
5. अपने CI में DB परिवर्तनों को शामिल करें - अपने परिवर्तनों को CI डेटाबेस पर लागू करें। इसके अलावा, यदि आपके पास कोई परीक्षण है जो डेटाबेस का उपयोग करता है, तो उन्हें प्रतिबद्ध पर चलाएं।

Comments

मुझे खुशी है कि मैं सहायता का

— पात्र बन गया

Answer 3

चूंकि आप phpMyAdmin का उपयोग कर रहे हैं, तो मुझे लगता है कि आप MySQL का भी उपयोग कर रहे हैं।

MySQL कार्यक्षेत्र में ईईआर मॉडल आरेखों पर एक नज़र डालें। स्कीमा को बनाए रखने और अद्यतन करने में उन्होंने मेरी बहुत मदद की है।

सबसे पहले, आप एक डेटाबेस स्रोत के साथ मॉडल को सिंक्रनाइज़ कर सकते हैं। ताकि आरेख में परिवर्तन को ALTER TABLE कमांड के रूप में धकेल दिया जाए। यह आपको आरेख पर अपने स्कीमा परिवर्तनों को करने की अनुमति देता है, इसे हमेशा अपडेट रखें जबकि जरूरत पड़ने पर अपने विकास डेटाबेस के अपडेट को भी धक्का दें।

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

तीसरा, इसका उपयोग SQL बनाने में सहायता के लिए किया जा सकता है जो आपकी "update.sql" फ़ाइल में जाना चाहिए।

कान्स:

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

यह डेटा माइग्रेशन टूल नहीं है। कोई भी परिवर्तन जो विशुद्ध रूप से स्कीमा से परे हैं, उन्हें अभी भी कस्टम SQL की आवश्यकता होगी।

Answer 4

Http://south.aeracode.org पर एक नजर डालें - यह Django (एक पायथन) के लिए एक DB पलायन पुस्तकालय है:

1. आप इससे बेहतरीन विचार प्राप्त कर सकते हैं (और शायद PHP क्लोन भी खोज सकते हैं)
2. आप वास्तव में अपने PHP / MySQL ऐप की तालिकाओं को प्रबंधित करने के लिए Django के बाकी हिस्सों से इसे स्वतंत्र रूप से उपयोग कर सकते हैं।

यह स्कीमा अपडेट स्क्रिप्ट भी उत्पन्न कर सकता है; यह अधिकांश समय स्वचालित रूप से बदलावों को भी संभालता है।

Comments

दुख की बात है, उन्होंने इसे Django कोर का हिस्सा बना दिया और अब अकेले खड़े नहीं होते

— Itay Moav -Malimovka