डीबी स्कीमा परिवर्तनों को ट्रैक करने के लिए तंत्र

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

फिर, स्क्रिप्ट को स्रोत नियंत्रण में उस कोड के साथ प्रतिबद्ध करें जो उस पर काम करता है। जब आपको कोड के साथ स्कीमा को बदलने की आवश्यकता होती है, तो स्क्रिप्ट को उस कोड के साथ चेक किया जा सकता है जिसके बदले स्कीमा की आवश्यकता होती है। फिर, स्क्रिप्ट पर diffs स्कीमा परिवर्तनों पर diffs इंगित करेगा।

इस स्क्रिप्ट के साथ, आप इसे डीबीयूनीट या किसी प्रकार की बिल्ड स्क्रिप्ट के साथ एकीकृत कर सकते हैं, इसलिए ऐसा लगता है कि यह आपकी पहले से स्वचालित प्रक्रियाओं में फिट हो सकता है।

यदि आप सी # का उपयोग कर रहे हैं, तो सबसनिक, एक बहुत ही उपयोगी ओआरएम उपकरण देखें, लेकिन आपकी योजना और \ या डेटा को फिर से बनाने के लिए एसक्यूएल स्क्रिप्ट भी उत्पन्न करता है। इन स्क्रिप्ट को तब स्रोत नियंत्रण में रखा जा सकता है।

http://subsonicproject.com/

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

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

अपनी स्कीमा को एक फ़ाइल में डंप करें और इसे स्रोत नियंत्रण में जोड़ें। फिर एक साधारण अंतर आपको दिखाएगा कि क्या बदल गया है।

हम एक बहुत ही सरल लेकिन अभी तक प्रभावी समाधान का उपयोग करते हैं।

नए इंस्टॉलेशन के लिए, हमारे पास भंडार में मेटाडेटा.sql फ़ाइल है जो सभी डीबी स्कीमा रखती है, फिर निर्माण प्रक्रिया में हम डेटाबेस को उत्पन्न करने के लिए इस फ़ाइल का उपयोग करते हैं।

अपडेट के लिए, हम हार्डकोडेड सॉफ़्टवेयर में अपडेट जोड़ते हैं। हम इसे कड़ी मेहनत करते हैं क्योंकि हम वास्तव में समस्या से पहले समस्याओं को हल करना पसंद नहीं करते हैं, और इस तरह की चीज अब तक एक समस्या साबित नहीं हुई है।

तो हमारे सॉफ्टवेयर में हमारे पास ऐसा कुछ है:

रजिस्टर अपग्रेड (1, 'वैकल्पिक तालिका XX XY CHAR जोड़ें (1) न्यूल;');

यह कोड जांच करेगा कि डेटाबेस संस्करण 1 में है (जो स्वचालित रूप से बनाए गए तालिका में संग्रहीत है), यदि यह पुराना है, तो आदेश निष्पादित किया गया है।

भंडार में metadata.sql को अद्यतन करने के लिए, हम स्थानीय रूप से इस उन्नयन को चलाते हैं और फिर पूर्ण डेटाबेस मेटाडेटा निकालते हैं।

एकमात्र चीज जो हर बार होती है, मेटाडाटा.sql को कम करना भूलना है, लेकिन यह एक बड़ी समस्या नहीं है क्योंकि बिल्ड प्रक्रिया पर परीक्षण करना आसान है और एकमात्र चीज जो हो सकती है वह एक नया इंस्टॉल करना है एक पुराना डेटाबेस और इसे पहले उपयोग पर अपग्रेड किया गया।

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

मैं बिल्ड संस्करणों के नाम पर फ़ोल्डरों का निर्माण करता हूं और वहां अपग्रेड और डाउनग्रेड स्क्रिप्ट डालता हूं। उदाहरण के लिए, आपके पास निम्न फ़ोल्डर्स हो सकते हैं: 1.0.0, 1.0.1 और 1.0.2। प्रत्येक में एक स्क्रिप्ट होती है जो आपको अपने डेटाबेस को संस्करणों के बीच अपग्रेड या डाउनग्रेड करने की अनुमति देती है।

क्या क्लाइंट या ग्राहक आपको संस्करण 1.0.1 के साथ किसी समस्या के साथ कॉल कर सकते हैं और आप 1.0.2 का उपयोग कर रहे हैं, डेटाबेस को अपने संस्करण में वापस लाने में कोई समस्या नहीं होगी।

अपने डेटाबेस में, "स्कीमा" नामक एक टेबल बनाएं जहां आप डेटाबेस के वर्तमान संस्करण में डालते हैं। फिर एक प्रोग्राम लिखना जो आपके लिए डेटाबेस को अपग्रेड या डाउनग्रेड कर सकता है, वह आसान है।

जॉय की तरह ही, अगर आप रेल की दुनिया में हैं, तो माइग्रेशन का उपयोग करें। :)

MySQL के लिए टोड में स्कीमा तुलना नामक एक फ़ंक्शन है जो आपको 2 डेटाबेस सिंक्रनाइज़ करने की अनुमति देता है। यह अब तक का सबसे अच्छा टूल है जिसका मैंने उपयोग किया है।

आईएमएचओ माइग्रेशन में बड़ी समस्या है:

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

वर्तमान संस्करण तक बेसलाइन के बाद से डेल्टा के पूरे इतिहास को चला रहा है (सैकड़ों ग्राहकों के डेटाबेस के लिए) बहुत लंबा समय ले सकता है।

के। स्कॉट एलन के पास स्कीमा वर्जनिंग पर एक सभ्य लेख या दो है, जो यहां अन्य उत्तरों में उल्लिखित वृद्धिशील अद्यतन स्क्रिप्ट / माइग्रेशन अवधारणा का उपयोग करता है; http://odetocode.com/Blogs/scott/archive/ देखें 2008/01/31 / 11710.aspx ।

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

डेटाबेस संरचना को सिंक्रनाइज़ करने के लिए, हमारे पास एक ही स्क्रिप्ट, update.php है, और 1.sql, 2.sql, 3.sql, आदि की संख्या वाली कई फ़ाइलें हैं। स्क्रिप्ट वर्तमान संस्करण संख्या को संग्रहीत करने के लिए एक अतिरिक्त तालिका का उपयोग करती है डेटाबेस। N.sql फ़ाइलों को डेटाबेस द्वारा संस्करण (एन -1) से संस्करण एन तक जाने के लिए हाथ से तैयार किया जाता है।

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

अद्यतन स्क्रिप्ट इस तरह काम करती है:

• Connect to the database.
• Make a backup of the current database (because stuff will go wrong) [mysqldump].
• Create bookkeeping table (called _meta) if it doesn't exist.
• Read current VERSION from _meta table. Assume 0 if not found.
• For all .sql files numbered higher than VERSION, execute them in order
• If one of the files produced an error: roll back to the backup
• Otherwise, update the version in the bookkeeping table to the highest .sql file executed.

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

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

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

Beware when pasting queries from phpMyAdmin though! Those generated queries usually include the database name, which you definitely don't want since it will break your scripts! Something like CREATE TABLE mydb.newtable(...) will fail if the database on the system is not called mydb. We created a pre-comment SVN hook that will disallow .sql files containing the mydb string, which is a sure sign that someone copy/pasted from phpMyAdmin without proper checking.

डीबी-तैनाती का प्रयास करें - मुख्य रूप से एक जावा उपकरण लेकिन PHP के साथ भी काम करता है।

• http://dbdeploy.com/
• http://davedevelopment.co.uk/2008/04/14/how-to-simple-database-migrations-with-phing-and-dbdeploy.html

रेल की दुनिया में, माइग्रेशन की अवधारणा है, स्क्रिप्ट्स जिसमें SQL में डेटाबेस-विशिष्ट स्वाद के बजाय डेटाबेस में परिवर्तन रूबी में किए जाते हैं। आपका रूबी माइग्रेशन कोड आपके वर्तमान डेटाबेस में विशिष्ट डीडीएल में परिवर्तित हो रहा है; यह डेटाबेस प्लेटफ़ॉर्म स्विचिंग को बहुत आसान बनाता है।

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

ruby on Rails migrations">This Oracle guide to Rails migrations covers migrations quite well.

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

मैंने कई परियोजनाओं के लिए विजुअल स्टूडियो में निम्न डेटाबेस प्रोजेक्ट स्ट्रक्चर का उपयोग किया है और यह बहुत अच्छी तरह से काम करता है:

डेटाबेस

स्क्रिप्ट बदलें

     

    

0.PreDeploy.sql

         

1.SchemaChanges.sql

         

2.DataChanges.sql

         

3.Permissions.sql

  

     

स्क्रिप्ट बनाएं

     

    

sprocs

         

कार्य

         

दृश्य

  

Our build system then updates the डेटाबेस from one version to the next by executing the scripts in the following order:

1.PreDeploy.sql

     

2.SchemaChanges.sql

     

स्क्रिप्ट फ़ोल्डर बनाने की सामग्री

     

2.DataChanges.sql

     

3.Permissions.sql

प्रत्येक डेवलपर प्रत्येक फ़ाइल के अंत में अपने कोड को जोड़कर किसी विशेष बग / फीचर के लिए अपने परिवर्तनों में जांच करता है। एक बार जब एक बड़ा संस्करण पूरा हो जाता है और स्रोत नियंत्रण में ब्रांच किया जाता है, तो बदलें स्क्रिप्ट फ़ोल्डर में .sql फ़ाइलों की सामग्री हटा दी जाती है।

मेरे वर्तमान PHP प्रोजेक्ट के लिए हम रेल माइग्रेशन के विचार का उपयोग करते हैं और हमारे पास एक माइग्रेशन निर्देशिका है जिसमें हम फाइल शीर्षक "migration_XX.sql" रखते हैं जहां एक्सएक्स माइग्रेशन की संख्या है। वर्तमान में इन फ़ाइलों को हाथ से बनाया गया है क्योंकि अपडेट किए गए हैं, लेकिन उनकी रचना को आसानी से संशोधित किया जा सकता है।

फिर हमारे पास "माइग्रेशन_वाचर" नामक एक स्क्रिप्ट है, जैसा कि हम प्री-अल्फा में हैं, वर्तमान में प्रत्येक पृष्ठ लोड पर चलता है और यह जांचता है कि कोई नया माइग्रेशन_XX.sql फ़ाइल है जहां XX वर्तमान माइग्रेशन संस्करण से बड़ा है। यदि ऐसा है तो यह डेटाबेस और voila के खिलाफ सबसे बड़ी संख्या तक सभी migration_XX.sql फ़ाइलों को चलाता है! स्कीमा परिवर्तन स्वचालित हैं।

यदि आपको सिस्टम को वापस करने की क्षमता की आवश्यकता होती है तो उसे बहुत अधिक ट्विकिंग की आवश्यकता होती है, लेकिन यह आसान है और अब तक हमारी काफी छोटी टीम के लिए बहुत अच्छा काम कर रहा है।

स्कॉट अंबालर लेखों की एक बड़ी श्रृंखला का उत्पादन करता है (और एक सह-लेखक http://www.ambysoft.com/books/refactoringDatabases.html" rel="noreferrer"> पुस्तक ) डेटाबेस रिफैक्टरिंग पर सह-लेखन करता है , इस विचार के साथ कि आपको अनिवार्य रूप से अपनी स्कीमा को बनाए रखने के लिए टीडीडी सिद्धांतों और प्रथाओं को लागू करना चाहिए। आपने डेटाबेस के लिए संरचना और बीज डेटा इकाई परीक्षणों की एक श्रृंखला स्थापित की है। फिर, कुछ भी बदलने से पहले, आप उस परिवर्तन को दर्शाने के लिए परीक्षणों को संशोधित / लिखते हैं।

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

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

मैं "स्क्रिप्टिंग" पक्ष के लिए चींटी (क्रॉस प्लेटफ़ॉर्म) का उपयोग करने की अनुशंसा करता हूं (क्योंकि यह व्यावहारिक रूप से जेडीबीसी के माध्यम से किसी भी डीबी से बात कर सकता है) और स्रोत भंडार के लिए सबवर्जन। परिवर्तन करने से पहले चींटी आपको स्थानीय फाइलों में अपने डीबी को "बैक अप" करने के लिए बाध्य करेगी। 1. चींटी मौजूदा डीबी स्कीमा चींटी के माध्यम से फ़ाइल करने के लिए 2. चींटी नियंत्रण एंट के माध्यम से सबवर्जन भंडार के लिए 3. चींटी के माध्यम से डीबी को नए एसक्यूएल स्टेटमेंट भेजें

एक कमांड लाइन mysql-diff टूल है जो डेटाबेस स्कीमा की तुलना करता है, जहां स्कीमा हो सकती है डिस्क पर एक लाइव डेटाबेस या एसक्यूएल स्क्रिप्ट। यह सबसे स्कीमा माइग्रेशन कार्यों के लिए अच्छा है।

यदि आप अभी भी समाधान ढूंढ रहे हैं: हम neXtep डिजाइनर नामक टूल का प्रस्ताव दे रहे हैं। यह एक डेटाबेस विकास वातावरण है जिसके साथ आप अपना संपूर्ण डेटाबेस संस्करण नियंत्रण के तहत रख सकते हैं। आप एक संस्करण नियंत्रित भंडार पर काम करते हैं जहां हर परिवर्तन को ट्रैक किया जा सकता है।

जब आपको एक अद्यतन जारी करने की आवश्यकता होती है, तो आप अपने घटकों को प्रतिबद्ध कर सकते हैं और उत्पाद स्वचालित रूप से पिछले संस्करण से SQL अपग्रेड स्क्रिप्ट उत्पन्न करेगा। बेशक, आप इस एसक्यूएल को किसी भी 2 संस्करणों से उत्पन्न कर सकते हैं।

फिर आपके पास कई विकल्प हैं: आप उन स्क्रिप्ट को ले सकते हैं और उन्हें अपने एप कोड के साथ अपने एसवीएन में डाल सकते हैं ताकि यह आपके मौजूदा तंत्र द्वारा तैनात किया जा सके। एक और विकल्प neXtep की डिलीवरी तंत्र का उपयोग करना है: स्क्रिप्ट को "डिलीवरी पैकेज" (एसक्यूएल स्क्रिप्ट्स + एक्सएमएल डिस्क्रिप्टर) नामक किसी चीज़ में निर्यात किया जाता है, और एक इंस्टॉलर इस पैकेज को समझ सकता है और स्ट्रक्चरल स्थिरता, निर्भरता सुनिश्चित करते समय इसे लक्षित सर्वर पर तैनात कर सकता है जांच, स्थापित संस्करण पंजीकृत, इत्यादि।

The product is GPL and is based on Eclipse so it runs on Linux, Mac and windows. It also support Oracle, Mysql and Postgresql at the moment (DB2 support is on the way). Have a look at the wiki where you will find more detailed information : http://www.nextep-softwares.com/wiki

मुझे तरीका है कि Yii डेटाबेस माइग्रेशन को कैसे प्रबंधित करता है। माइग्रेशन मूल रूप से एक PHP स्क्रिप्ट है जिसे CDbMigration लागू किया जाता है। सीडीबी माइग्रेशन एक ऊपर विधि को परिभाषित करता है जिसमें माइग्रेशन तर्क होता है। माइग्रेशन के उलट का समर्थन करने के लिए down विधि को कार्यान्वित करना भी संभव है। वैकल्पिक रूप से, safeUp या safeDown का उपयोग यह सुनिश्चित करने के लिए किया जा सकता है कि माइग्रेशन लेनदेन के संदर्भ में किया जाता है।

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

अधिक जानकारी के लिए मैन्युअल से डेटाबेस माइग्रेशन आलेख देखें।