डेटाबेस के संस्करणों को नियंत्रित करने और संस्करणों के बीच माइग्रेशन की समस्याओं को बार-बार Habré ( 1 , 2 , 3 , आदि) और इंटरनेट (मुख्य रूप से अंग्रेजी) दोनों पर उठाया गया है।

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

शब्दावली

एक डेटाबेस सभी डेटाबेस ऑब्जेक्ट्स (तालिकाओं, प्रक्रियाओं, ट्रिगर, आदि), स्थिर डेटा (लुकअप तालिकाओं में संग्रहीत अपरिवर्तनीय डेटा) और उपयोगकर्ता डेटा (जो एप्लिकेशन के साथ काम के दौरान बदलते हैं) का एक संग्रह है।

डेटाबेस संरचना - सभी डेटाबेस ऑब्जेक्ट और स्थिर डेटा का एक सेट। उपयोगकर्ता डेटा डेटाबेस संरचना की अवधारणा में शामिल नहीं है।

डेटाबेस संस्करण - डेटाबेस संरचना की एक विशिष्ट स्थिति। आमतौर पर, संस्करण में एप्लिकेशन के संस्करण संख्या के साथ संबद्ध संख्या होती है।

माइग्रेशन , इस संदर्भ में, डेटाबेस संरचना को एक संस्करण से दूसरे (आमतौर पर एक नया) अपडेट कर रहा है।

इस अर्थ में, प्रवासन शब्द का उपयोग कई स्रोतों में किया जाता है (विशेष रूप से सक्रिय रिकॉर्ड मणि से पलायन , जो रूबी ऑन रेल्स का हिस्सा है, ने इसमें योगदान दिया)। हालांकि, इस शब्द का उपयोग करते समय, अस्पष्टता उत्पन्न होती है: एक व्यक्ति जिसे संदर्भ नहीं पता है, बल्कि यह सोचेंगे कि यह एक डेटाबेस को एक DBMS से दूसरे (MySQL => Oracle) में स्थानांतरित करने का सवाल है, या क्लस्टर नोड्स के लिए प्रक्रियाओं / डेटा का भी माइग्रेशन। इसलिए, मैं प्रस्तावित करता हूं, ऐसे मामलों में जहां संदर्भ स्पष्ट नहीं है, एक अधिक सटीक शब्द का उपयोग करने के लिए: संस्करण डेटाबेस माइग्रेशन ।

इसकी आवश्यकता क्यों है?

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

डेटाबेस संस्करण को एप्लिकेशन संस्करण से मेल खाना चाहिए

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

1. फ़ील्ड प्रकार को अशक्त करने के लिए बदलें:

ALTER myTable CHANGE COLUMN myField myField VARCHAR (255) NULL DEFAULT NULL ;

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

UPDATE myTable SET myField = NULL WHERE myField = '' ;

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

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

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

क्या यह इतना आसान है?

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

यहाँ हम फिर से एक जीवित उदाहरण की ओर मुड़ते हैं। मान लीजिए, विकास प्रक्रिया में प्रोग्रामर डेटाबेस की संरचना और डेटा में SQL क्वेरी ( DDL और DML क्वेरी दोनों) के रूप में एक अलग फ़ाइल में अपने परिवर्तन लिखते हैं। और एप्लिकेशन के नवीनतम संस्करण की प्रत्येक परिनियोजन के साथ, आप डेटाबेस को नवीनतम रूप से नवीनतम संस्करण में अपडेट करते हैं, उसी SQL फ़ाइल से क्वेरीज़ करते हैं ... लेकिन प्रतीक्षा करें, आप किस संस्करण से डेटाबेस को नवीनतम संस्करण में अपडेट करते हैं? "अतीत से"? लेकिन क्या आपको इतनी अच्छी तरह याद है कि वास्तव में पिछला संस्करण क्या था (यह 2 महीने पहले जारी किया गया था)? यदि नहीं, तो आप इसे कैसे अपडेट करेंगे? दरअसल, संरचना और डेटा की स्थिति के बारे में सटीक जानकारी के बिना, सही ढंग से माइग्रेट करना असंभव है: यदि आप अनजाने में पहले से निष्पादित किए गए प्रश्नों को निष्पादित करते हैं, तो इससे डेटा का नुकसान हो सकता है या इसकी अखंडता का उल्लंघन हो सकता है।
एक सरल उदाहरण उनके एमडी 5 रकम के साथ पासवर्ड की जगह है। यदि आप ऐसे अनुरोध को फिर से निष्पादित करते हैं, तो डेटा केवल बैकअप से बहाल किया जा सकता है। वैसे भी, कोई भी UPDATE , DELETE और यहां तक ​​कि बार-बार किए गए INSERT के परिणाम भी बेहद अवांछनीय परिणाम दे सकते हैं। असत्य TRUNCATE उल्लेख और DROP के (हालांकि इस तरह के मामलों की संभावना बहुत कम है) का उल्लेख नहीं है।
वैसे, इस दृष्टिकोण से, अंडरफिलमेंट ओवरफिलमेंट की तुलना में एप्लिकेशन की संचालन क्षमता के लिए कम खतरा नहीं है।

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

संस्करणित प्रवास के सामान्य सिद्धांत

पिछले अनुभाग में, हमने महत्वपूर्ण मानदंड की पहचान की जो दिखाते हैं कि संस्करणबद्ध प्रवासन प्रक्रिया की क्या आवश्यकता है। यह है:

• प्रत्येक परिवर्तन (SQL क्वेरी) का एक बार निष्पादन;
• परिवर्तनों का पूर्वनिर्धारित क्रम।

अब माइग्रेशन बनाने और संग्रहीत करने की प्रक्रिया से क्या मांगें समझने के लिए अधिक व्यावहारिक मानदंड पर प्रकाश डालें। मेरी राय में, अधिकांश विकास टीमों के लिए यह महत्वपूर्ण होगा:

• ताकि डेटाबेस के किसी भी संस्करण को किसी भी (आमतौर पर, नवीनतम) संस्करण में अपडेट किया जा सके;
• ताकि किसी भी दो संस्करणों के बीच प्रवास को लागू करने वाले SQL प्रश्नों का एक सेट जल्दी और आसानी से प्राप्त किया जा सके;
• ताकि आप हमेशा स्क्रैच से नवीनतम संस्करण की संरचना के साथ एक डेटाबेस बना सकें। यह विकास और परीक्षण प्रक्रिया दोनों में बहुत उपयोगी है, और जब एक नया उत्पादन सर्वर तैनात करता है;
• इसलिए, विभिन्न शाखाओं पर काम के मामले में, उनके बाद के विलय पर, डेटाबेस फ़ाइलों का मैन्युअल संपादन कम से कम किया जाता है;
• पहले वाले संस्करण में एक डेटाबेस को वापस रोल करना उतना ही सरल था जितना कि किसी नए को अपडेट करना।

प्रवास का आधार

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

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

अगला, हम संस्करणित डेटाबेस माइग्रेशन के आयोजन के लिए तीन दृष्टिकोणों पर विचार करेंगे।

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

यह विधि उसी स्कॉट एलन के "संस्करण डेटाबेस - परिवर्तन लिपियों" लेख में अच्छी तरह से वर्णित है। माइकल बेलॉन द्वारा "एसक्यूएल लिपियों का प्रबंधन और निरंतर एकीकरण" लेख में एक समान दृष्टिकोण का भी वर्णन किया गया है।

फ़ाइल संरचना

इस मामले में माइग्रेशन फ़ाइलों वाला फ़ोल्डर कैसे दिखाई दे सकता है, इसका एक उदाहरण:

Database
|- Baseline.sql
|- 0001. 03 .01.sql
|- 0002. 03 .01.sql
|- 0003. 03 .01.sql
|- 0004. 03 .02.sql
|- 0005. 03 .02.sql
|- 0006. 03 .02.sql
'- 0007. 03 .02.sql

इस उदाहरण में, फ़ोल्डर संस्करण 03 के विकास के दौरान बनाई गई सभी फ़ाइलों को संग्रहीत करता है। हालाँकि, फ़ोल्डर अनुप्रयोग के सभी संस्करणों के लिए सामान्य हो सकता है।

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

वास्तव में, इस उदाहरण में, फ़ाइल नाम में डेटाबेस का पूर्ण संस्करण संख्या शामिल है। अर्थात्, 0006 .03.02.sql नाम के साथ माइग्रेशन फ़ाइल 0006 .03.02.sql डेटाबेस को राज्य से संस्करण 03.02. 0005 अनुरूप अपडेट किया जाएगा 03.02. 0005 03.02. 0005 , संस्करण 03.02. 0006 03.02. 0006 ।

संस्करण इतिहास भंडारण

अगला कदम डेटाबेस में एक विशेष तालिका जोड़ना है, जो डेटाबेस में सभी परिवर्तनों के इतिहास को संग्रहीत करेगा।

CREATE TABLE MigrationHistory
(
Id INT ,
MajorVersion VARCHAR (2),
MinorVersion VARCHAR (2),
FileNumber VARCHAR (4),
Comment VARCHAR (255),
DateApplied DATETIME ,

PRIMARY KEY (Id)
)


यह केवल एक उदाहरण है कि तालिका कैसे दिख सकती है। यदि आवश्यक हो, तो यह सरलीकृत और पूरक दोनों हो सकता है।

Baseline.sql फ़ाइल में, आपको इस तालिका में पहला रिकॉर्ड जोड़ना होगा:

INSERT INTO
MigrationHistory ( MajorVersion, MinorVersion, FileNumber, Comment, DateApplied )
VALUES ( '03' , '01' , '0000' , 'Baseline' , NOW() )


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

स्वचालित रूप से माइग्रेट करें

इस दृष्टिकोण में अंतिम स्पर्श एक प्रोग्राम / स्क्रिप्ट है जो डेटाबेस को वर्तमान संस्करण से नवीनतम में अपडेट करेगा।

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

इस तरह की स्क्रिप्ट में माइग्रेशनहॉस्टर टेबल में पूर्ण माइग्रेशन के रिकॉर्ड को जोड़ने का कार्य भी है।

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

पेशेवरों, विपक्ष, निष्कर्ष

नवीनतम संस्करण के लिए त्वरित और आसान प्रवास;
संस्करण संख्या तंत्र। वर्तमान संस्करण संख्या सीधे डेटाबेस में संग्रहीत होती है;
अधिकतम सुविधा के लिए, आपको माइग्रेशन के लिए स्वचालन उपकरण की आवश्यकता होती है;
डेटाबेस संरचना में टिप्पणियों को जोड़ना असुविधाजनक है। यदि आप उन्हें Baseline.sql में जोड़ते हैं, तो अगले संस्करण में वे गायब हो जाएंगे, क्योंकि आधार फिर से खरोंच से उत्पन्न होगा, संरचना के नए संस्करण के डंप के रूप में। इसके अलावा, ऐसी टिप्पणियां जल्दी से अप्रचलित हो जाएंगी;
रिपॉजिटरी की कई शाखाओं में समानांतर विकास प्रक्रिया के दौरान समस्याएं हैं। चूंकि माइग्रेशन फ़ाइलों की संख्या अनुक्रमिक है, इसलिए विभिन्न शाखाओं में एक ही नंबर के तहत अलग-अलग डीडीएल / डीएमएल अनुरोध वाली फाइलें दिखाई दे सकती हैं। परिणामस्वरूप, जब शाखाओं को विलय करते हैं, तो आपको या तो फ़ाइलों और उनके अनुक्रम को मैन्युअल रूप से संपादित करना होगा, या एक नई, "विलय" शाखा में, नए बेसलाइन के साथ शुरू करना होगा। एससीएल, जो दोनों शाखाओं से खाता परिवर्तन में लेता है।

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

आदर्श परिवर्तन विधि

इस विधि का वर्णन फिल हैक के बुलेटप्रूफ Sql Change Scripts में INFORMATION_SCHEMA व्यूज का उपयोग करके किया गया है । StackOverflow पर इस प्रश्न के उत्तर में एक समान दृष्टिकोण भी वर्णित है।

बेरोजगारी को किसी वस्तु के अपरिवर्तित रहने के रूप में समझा जाता है जब वह इसे बदलने के लिए फिर से कोशिश करता है।
विषय "मित्र" से एक अजीब दृश्य याद करते हैं :)

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

इस विचार को एक उदाहरण के साथ समझना सबसे आसान है। मान लीजिए आपको डेटाबेस में एक नई तालिका जोड़ने की आवश्यकता है। यदि आप यह सुनिश्चित करना चाहते हैं कि यदि यह पहले से मौजूद है, तो क्वेरी निष्पादित करते समय कोई त्रुटि नहीं है, इन उद्देश्यों के लिए MySQL का एक छोटा सिंटैक्स है:

CREATE TABLE IF NOT EXISTS myTable
(
id INT (10) NOT NULL ,
myField VARCHAR (255) NULL ,
PRIMARY KEY (id)
);

IF NOT EXISTS कीवर्ड के लिए धन्यवाद, MySQL केवल एक तालिका बनाने का प्रयास करेगा यदि उसी नाम वाली तालिका पहले से मौजूद नहीं है। हालाँकि, यह सिंटैक्स सभी DBMS में उपलब्ध नहीं है; इसके अलावा, MySQL में भी इसका उपयोग सभी कमांड के लिए नहीं किया जा सकता है। इसलिए, हम एक अधिक सार्वभौमिक तरीके पर विचार करते हैं:

IF NOT EXISTS
(
SELECT *
FROM information_schema.tables
WHERE table_name = 'myTable'
AND table_schema = 'myDb'
)
THEN
CREATE TABLE myTable
(
id INT (10) NOT NULL ,
myField VARCHAR (255) NULL ,
PRIMARY KEY (id)
);
END IF ;

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

यह ध्यान देने योग्य है कि MySQL में, किसी कारण के लिए, सशर्त अभिव्यक्तियों के अंदर DDL प्रश्नों को निष्पादित करना निषिद्ध है। लेकिन इस निषेध को दरकिनार करना आसान है - बस संग्रहीत प्रक्रिया के शरीर में ऐसे सभी अनुरोध शामिल करें:

DELIMITER $$

CREATE PROCEDURE sp_tmp() BEGIN

IF NOT EXISTS
(
--
-- .
--
)
THEN
--
-- , .
--
END IF ;

END ;
$$

DELIMITER;

CALL sp_tmp();

DROP PROCEDURE sp_tmp;

किस तरह का पक्षी है info_schema?

डेटाबेस संरचना के बारे में पूरी जानकारी डेटाबेस में स्थित विशेष सिस्टम तालिकाओं से प्राप्त की जा सकती है जिसका नाम information_schema । यह डेटाबेस और इसकी तालिकाएँ SQL-92 मानक का हिस्सा हैं, इसलिए इस पद्धति का उपयोग किसी भी आधुनिक DBMS पर किया जा सकता है। पिछला उदाहरण info_schema.tables तालिका का उपयोग करता है, जो सभी तालिकाओं के बारे में डेटा संग्रहीत करता है। इसी तरह, आप तालिकाओं, संग्रहीत प्रक्रियाओं, ट्रिगर, स्कीमा और, वास्तव में, डेटाबेस संरचना में किसी भी अन्य वस्तुओं के क्षेत्र के अस्तित्व और मेटाडेटा की जांच कर सकते हैं।

उनके उद्देश्य के बारे में विस्तृत जानकारी के साथ तालिकाओं की एक पूरी सूची मानक के पाठ में पाई जा सकती है। एक छोटी सूची को पहले ही उल्लिखित फिल हैक लेख में देखा जा सकता है। लेकिन सबसे आसान तरीका, निश्चित रूप से किसी भी कार्यशील डेटाबेस सर्वर पर इस डेटाबेस को खोलना है और देखें कि यह कैसे काम करता है।

उदाहरण का उपयोग करें

तो, आपको पता है कि idempotent SQL क्वेरी कैसे बनाते हैं। अब हम इस बात पर विचार करेंगे कि व्यवहार में इस दृष्टिकोण का उपयोग कैसे किया जा सकता है।

इस मामले में sql फ़ाइलों वाला फ़ोल्डर कैसे दिख सकता है, इसका एक उदाहरण:

Database
|- 3.01
| |- Baseline.sql
| '- Changes.sql
|
'- 3.02
|- Baseline.sql
'- Changes.sql

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

मान लीजिए, अलग-अलग समय पर विकास के दौरान, प्रोग्रामर को डेटाबेस में निम्नलिखित परिवर्तनों की आवश्यकता होती है:
a) एक तालिका myTable बनाएँ;
बी) इसमें एक नया क्षेत्र जोड़ें;
ग) myTable तालिका में कुछ डेटा जोड़ें।

तीनों परिवर्तन लिखे जाते हैं ताकि दोहराया न जाए। नतीजतन, कोई फर्क नहीं पड़ता कि कौन सा मध्यवर्ती डेटाबेस डेटाबेस में है, जब Changes.sql फ़ाइल निष्पादित होती है, तो यह हमेशा नवीनतम संस्करण में माइग्रेट किया जाएगा।

उदाहरण के लिए, डेवलपर्स में से एक ने डेटाबेस की अपनी स्थानीय प्रति पर myTable तालिका बनाई, परिवर्तन को a) को बदल दिया। सामान्य कोड रिपॉजिटरी में संग्रहीत Changes.sql फ़ाइल में, और कुछ समय के लिए इसके बारे में भूल गया। अब, यदि वह अपने स्थानीय डेटाबेस पर इस फ़ाइल को निष्पादित करता है, तो a) को नजरअंदाज कर दिया जाएगा, और b) और c) को लागू कर दिया जाएगा।

पेशेवरों, विपक्ष, निष्कर्ष

किसी भी मध्यवर्ती संस्करण से नवीनतम तक बहुत सुविधाजनक प्रवास - आपको बस डेटाबेस पर एक फ़ाइल निष्पादित करने की आवश्यकता है (Changes.sql);
संभावित रूप से संभावित स्थिति जिसमें डेटा खो जाएगा, इस पर नजर रखनी होगी। एक उदाहरण एक तालिका को हटा रहा है, और फिर उसी नाम से एक और तालिका बना रहा है। यदि विलोपन के दौरान केवल नाम की जांच की जाती है, तो दोनों ऑपरेशन (विलोपन और निर्माण) प्रत्येक बार स्क्रिप्ट निष्पादित होने के बाद होंगे, इस तथ्य के बावजूद कि वे एक बार किए गए थे;
बदलावों को आदर्श बनाने के लिए, आपको उन्हें लिखने के लिए अधिक समय (और कोड) खर्च करना होगा।

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

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

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

इस पद्धति का मुख्य विचार हेडर में परिलक्षित होता है: डेटाबेस संरचना PHP, C # या HTML कोड के समान स्रोत कोड है। इसलिए, कोड रिपॉजिटरी में माइग्रेशन फ़ाइलों (डेटाबेस संरचना को बदलने वाले प्रश्नों के साथ) के बजाय, आपको केवल वर्तमान डेटाबेस संरचना - एक घोषणात्मक रूप में संग्रहीत करने की आवश्यकता है।

कार्यान्वयन का उदाहरण

उदाहरण की सादगी के लिए, हम मानते हैं कि रिपॉजिटरी के प्रत्येक संशोधन में हमेशा केवल एक एसक्यूएल-फ़ाइल होगी: CreateDatabase.sql। कोष्ठक में, मैं ध्यान देता हूं कि स्रोत कोड के अनुरूप, आप आगे भी जा सकते हैं और प्रत्येक डेटाबेस ऑब्जेक्ट की संरचना को एक अलग फ़ाइल में संग्रहीत कर सकते हैं। साथ ही, संरचना को XML या अन्य स्वरूपों के रूप में संग्रहीत किया जा सकता है जो आपके DBMS द्वारा समर्थित हैं।

CreateDatabase.sql फ़ाइल में CREATE TABLE , CREATE PROCEDURE , आदि कमांड होंगे जो पूरे डेटाबेस को स्क्रैच से बनाते हैं। यदि आवश्यक हो, तो तालिकाओं की संरचना में परिवर्तन, ये परिवर्तन तालिकाओं को बनाने के लिए मौजूदा DDL- प्रश्नों से सीधे किए जाते हैं। वही संग्रहीत प्रक्रियाओं, ट्रिगर आदि के परिवर्तनों के लिए जाता है।

उदाहरण के लिए, रिपॉजिटरी के वर्तमान संस्करण में पहले से ही एक तालिका myTable है, और CreateDatabase.sql फ़ाइल में यह इस तरह दिखता है:

CREATE TABLE myTable
(
id INT (10) NOT NULL ,
myField VARCHAR (255) NULL ,
PRIMARY KEY (id)
);

यदि आपको इस तालिका में एक नया फ़ील्ड जोड़ने की आवश्यकता है, तो आप इसे मौजूदा DDL क्वेरी में जोड़ सकते हैं:

CREATE TABLE myTable
(
id INT (10) NOT NULL ,
myField VARCHAR (255) NULL ,
newfield INT(4) NOT NULL ,
PRIMARY KEY (id)
);

उसके बाद, संशोधित sql फ़ाइल कोड रिपॉजिटरी को सबमिट की जाती है।

संस्करणों के बीच पलायन करना

इस विधि में, डेटाबेस को एक नए संस्करण में अद्यतन करने की प्रक्रिया अन्य विधियों की तरह सीधी नहीं है। चूंकि प्रत्येक संस्करण के लिए संरचना का केवल एक घोषणात्मक विवरण संग्रहीत किया जाता है, प्रत्येक प्रवास के लिए ALTER -, DROP - और CREATE अनुरोध के रूप में अंतर उत्पन्न करना आवश्यक है। ऑटोमैटिक डिफरेंशियल यूटिलिटीज इसमें आपकी मदद करेगी, जैसे स्कीमा सिंक्रोनाइजेशन टूल, जो SQLYog , TOAD का हिस्सा है, जो कई DBMS के लिए उपलब्ध है, डिक्लेरीबॉटेरोव द्वारा PostgreSQL के लिए Dklab_pgmigrator , साथ ही RedGate से SQL तुलना एसडीके ।

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

डेटा परिवर्तन के बारे में क्या?

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

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

इस समस्या के कई और कम स्वीकार्य समाधान हैं:

• वृद्धिशील परिवर्तन विधि (संभवतः एक सरलीकृत रूप में) के अनुसार डेटा परिवर्तनों को संग्रहीत करें और उन्हें अपनी पीढ़ी के बाद परिणामी रूप से अलग स्क्रिप्ट में जोड़ें, मैन्युअल रूप से;
• डेटा परिवर्तन अनुरोधों को संग्रहीत करने के लिए कहीं नहीं है, और जब अलग स्क्रिप्ट उत्पन्न होती है, तो इसका विश्लेषण करें और सभी आवश्यक डीएमएल अनुरोधों को जगह में जोड़ें। मैं यह निर्णय केवल इसलिए ले आया क्योंकि मेरे सहयोगी का कहना है कि यह काम कर रहा है और इसमें कोई कमी नहीं है; मुझे यह बहुत खतरनाक लगता है, क्योंकि परिवर्तन स्क्रिप्ट की पीढ़ी संभावित रूप से परिवर्तन के अनुप्रयोग-संबंधित भाग पर काम करने के कई महीने बाद हो सकती है, और सही डेटा माइग्रेशन के लिए आवश्यक विवरण पहले से ही भूल सकते हैं।

पेशेवरों, विपक्ष, निष्कर्ष

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

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

संस्करण डेटाबेस प्रवास के लिए तैयार समाधान

ऊपर वर्णित तरीकों का उपयोग तीसरे पक्ष के समाधान के बिना किया जा सकता है, हालांकि, तैयार-से-उपयोग उत्पाद भी हैं, प्रत्येक की अपनी विचारधारा और मूल दृष्टिकोण, एक अलग लेख के योग्य है। जब एक संस्करण प्रवासन समाधान चुनते हैं, तो ऐसे उत्पादों पर भी विचार करना सुनिश्चित करें। डेनिस ग्लैडकिख द्वारा

उनमें से कुछ पर हाल ही में एक लेख में चर्चा की गई है, "संस्करण के लिए दृष्टिकोण," । संस्करण-तैयार माइग्रेशन सिस्टम का केवल एक छोटा हिस्सा जो उपयोग करने के लिए तैयार है, वे नीचे सूचीबद्ध हैं:

• माइग्रेटर .नेट ;
• ECM7.Migrator — Migrator.NET dima117 . ;
• Active Record Migrations , Ruby on Rails;
• SQL Source Control RedGate;
• DotNetMigrations ;
• Fluent Migrator . tabushi , ;
• DbDeploy.NET ;
• Tarantino ;
• Mygrate ;
• DBUpdater ;
• Wizardby ostapbender .

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