database - मैं गिट(संस्करण नियंत्रण) के तहत डेटाबेस कैसे रख सकता हूं?




git version-control (16)

मैं पूरे डेटाबेस को वर्जन कंट्रोल के तहत रखना चाहता हूं, मैं किस डेटाबेस इंजन का उपयोग कर सकता हूं ताकि मैं अपने डंप के बजाय वर्जन कंट्रोल के तहत वास्तविक डेटाबेस डाल सकूं?

यह डेटाबेस इंजन निर्भर नहीं है। माइक्रोसॉफ्ट एसक्यूएल सर्वर द्वारा बहुत सारे संस्करण नियंत्रण कार्यक्रम हैं। मुझे नहीं लगता कि समस्या को गिट के साथ हल किया जा सकता है, आपको एक pgsql विशिष्ट स्कीमा संस्करण नियंत्रण प्रणाली का उपयोग करना होगा। मुझे नहीं पता कि ऐसी चीज मौजूद है या नहीं ...

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

मैं उसको कैसे करू? क्या कोई विशिष्ट फ़ोल्डर है जिसे मैं एक गिट भंडार के तहत रख सकता हूं? मैं कैसे जानूं? मैं कैसे सुनिश्चित कर सकता हूं कि मैं सही फ़ोल्डर डाल रहा हूं?

मुझे यकीन है कि, क्योंकि ये परिवर्तन पिछड़े संगत नहीं हैं; मैं पेंच करने के लिए बर्दाश्त नहीं कर सकता।

मेरे मामले में डेटाबेस PostgreSQL है

संपादित करें:

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

कोई बेहतर तरीका ज़रूर होगा।

अद्यतन करें:

ठीक है, तो कोई बेहतर तरीका नहीं है, लेकिन मैं अभी भी पूरी तरह से आश्वस्त नहीं हूं, इसलिए मैं सवाल थोड़ा सा बदल दूंगा:

मैं पूरे डेटाबेस को वर्जन कंट्रोल के तहत रखना चाहता हूं, मैं किस डेटाबेस इंजन का उपयोग कर सकता हूं ताकि मैं अपने डंप के बजाय वर्जन कंट्रोल के तहत वास्तविक डेटाबेस डाल सकूं?

Sqlite गिट-अनुकूल होगा?

चूंकि यह केवल विकास पर्यावरण है, इसलिए मैं जो भी डेटाबेस चाहता हूं उसे चुन सकता हूं।

EDIT2:

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


IBatis Migrations ( manual , शॉर्ट ट्यूटोरियल वीडियो ) जैसे टूल का उपयोग करें जो आपको डेटाबेस के बजाए किसी प्रोजेक्ट के जीवन चक्र में डेटाबेस में किए गए परिवर्तनों को नियंत्रित करने की अनुमति देता है।

यह आपको अलग-अलग वातावरण में व्यक्तिगत परिवर्तनों को चुनिंदा रूप से लागू करने की अनुमति देता है, परिवर्तनों को बदलने के लिए वातावरण में कौन से परिवर्तन होते हैं, परिवर्तनों को लागू करने के लिए स्क्रिप्ट बनाते हैं, एन, रोलबैक परिवर्तन आदि के माध्यम से ए।


आप इसे परमाणुता के बिना नहीं कर सकते हैं, और आप pg_dump या स्नैपशॉटिंग फाइल सिस्टम का उपयोग किए बिना परमाणु नहीं प्राप्त कर सकते हैं।

मेरा पोस्टग्रेस इंस्टेंस जेएफएस पर है, जिसे मैं कभी-कभी स्नैपशॉट करता हूं। यह लगभग तत्काल और सुसंगत है।


आप जो चाहते हैं, आत्मा में शायद पोस्ट फैक्टो की तरह कुछ है, जो डेटाबेस में डेटाबेस के संस्करणों को संग्रहीत करता है। इस presentation जांच करें।

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


इस सवाल का काफी जवाब दिया गया है, लेकिन मैं एक्स-इस्टेंस और साना के जवाब को एक छोटे से सुझाव के साथ पूरक करना चाहता हूं।

यदि आपको कुछ डिग्री ग्रैन्युलरिटी के साथ संशोधन नियंत्रण की आवश्यकता है, तो दैनिक कहें, आप दोनों टेबलों और स्कीमा के टेक्स्ट डंप को rdiff-backup जैसे टूल के साथ rdiff-backup जो वृद्धिशील बैकअप करता है। लाभ यह है कि दैनिक बैकअप के स्नैपशॉट्स को संग्रहीत करने के बजाय, आप केवल पिछले दिन से अंतर को स्टोर करते हैं।

इसके साथ आपके पास संशोधन नियंत्रण का दोनों लाभ हैं और आप बहुत अधिक जगह बर्बाद नहीं करते हैं।

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


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

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


कोड परिवर्तनों के साथ अपने डेटाबेस को बनाए रखने के लिए अच्छी तकनीकों के समूह के लिए रिफैक्टरिंग डेटाबेस ( http://databaserefactoring.com/ ) देखें।

कहने का पर्याप्त कारण है कि आप गलत सवाल पूछ रहे हैं। अपने डेटाबेस को गिट में डालने के बजाय आपको अपने परिवर्तनों को छोटे सत्यापन योग्य चरणों में विघटित करना चाहिए ताकि आप आसानी से माइग्रेट / रोलबैक स्कीमा परिवर्तनों को माइग्रेट कर सकें।

यदि आप पूर्ण वसूली योग्यता प्राप्त करना चाहते हैं तो आपको अपने पोस्टग्रेज़ वाल लॉग संग्रहित करने पर विचार करना चाहिए और विशिष्ट ज्ञात अच्छे राज्यों को वापस / आगे लेनदेन खेलने के लिए पीआईटीआर (समय वसूली में बिंदु) का उपयोग करना चाहिए।


गिट वर्जनिंग नियंत्रण के तहत डेटाबेस स्तर के प्रत्येक स्तर को संग्रहीत करना प्रत्येक प्रतिबद्धता के साथ अपने पूरे डेटाबेस को धक्का देना और प्रत्येक पुल के साथ अपना संपूर्ण डेटाबेस बहाल करना है। यदि आपका डेटाबेस महत्वपूर्ण परिवर्तनों के लिए बहुत प्रवण है और आप उन्हें खोने का जोखिम नहीं उठा सकते हैं, तो आप बस अपने pre_commit और post_merge हुक अपडेट कर सकते हैं। मैंने अपनी परियोजनाओं में से एक के साथ ऐसा किया और आप here दिशानिर्देश पा सकते हैं।


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


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

उपर्युक्त उत्तरों का सारांश, समान रूप से पूछे जाने वाले समस्या का वैकल्पिक समाधान सुझाता है, जो डाटाबेस में कुछ प्रबंधित करने के लिए गिट का उपयोग करने के बिंदु को याद करता है, इसलिए मैं उस प्रश्न का उत्तर देने का प्रयास करूंगा।

गिट एक प्रणाली है, जो संक्षेप में डेल्टा (मतभेद) का डेटाबेस संग्रहीत करती है, जिसे संदर्भ को दोबारा बनाने के लिए पुनः संयोजित किया जा सकता है। गिट का सामान्य उपयोग मानता है कि संदर्भ एक फाइल सिस्टम है, और उन डेल्टा उस फ़ाइल सिस्टम में भिन्न हैं, लेकिन वास्तव में सभी गिट, डेल्टास का पदानुक्रमित डेटाबेस है (पदानुक्रमिक, क्योंकि ज्यादातर मामलों में प्रत्येक डेल्टा कम से कम 1 के साथ प्रतिबद्ध है माता-पिता, एक पेड़ में व्यवस्थित)।

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

यदि आप डेटाबेस में परिवर्तन का प्रबंधन करना चाहते हैं, तो आपके पास 2 अलग-अलग समस्याएं हैं, और मैं उन्हें अलग से संबोधित करूंगा (अगर मैं आप थे)। पहला स्कीमा है, दूसरा डेटा है (हालांकि आपके प्रश्न में, आप डेटा डेटा ऐसा कुछ नहीं है जिसके बारे में आप चिंतित हैं)। एक समस्या जो मैंने पहले की थी, वह देव और प्रोड डेटाबेस था, जहां देव स्कीमा में वृद्धिशील परिवर्तन ले सकता था, और उन परिवर्तनों को सीवीएस में दस्तावेज किया जाना था, और कई 'स्थिर' में से एक के साथ-साथ रहने के लिए प्रचारित किया जाना था। टेबल। हमने क्रूज़ नामक तीसरा डेटाबेस करके ऐसा किया, जिसमें केवल स्थिर डेटा था। किसी भी समय देव और क्रूज़ की स्कीमा की तुलना की जा सकती है, और हमारे पास उन 2 फाइलों का अंतर लेने के लिए एक स्क्रिप्ट थी और इसे लागू करने के लिए ALTER कथन वाले SQL फ़ाइल का उत्पादन किया गया था। इसी प्रकार और नया डेटा, आईएनएसईआरटी कमांड वाली एक SQL फ़ाइल में आसवित किया जा सकता है। जब तक फ़ील्ड और टेबल केवल जोड़े जाते हैं, और कभी नहीं हटाए जाते हैं, तो प्रक्रिया डेल्टा लागू करने के लिए SQL कथन उत्पन्न करने को स्वचालित कर सकती है।

जिस तंत्र द्वारा गेट उत्पन्न करता है वह तंत्र diff और जिस तंत्र द्वारा फ़ाइल के साथ 1 या अधिक डेल्टा को जोड़ दिया जाता है, उसे merge कहा जाता है। यदि आप अलग-अलग संदर्भ से अलग होने और विलय करने के लिए एक विधि के साथ आ सकते हैं, तो गिट काम करना चाहिए, लेकिन जैसा कि चर्चा की गई है, आप एक ऐसा उपकरण पसंद कर सकते हैं जो आपके लिए करता है। यह हल करने की दिशा में मेरा पहला विचार यह है कि यह https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#External-Merge-and-Diff-Tools कॉन्फ़िगरेशन ^External-Merge-and-Diff-Tools जो विवरण देता है कि गिट के आंतरिक diff को कैसे बदलें और उपकरण मर्ज करें। मैं इस जवाब को अपडेट कर दूंगा, क्योंकि मैं समस्या के बेहतर समाधान के साथ आता हूं, लेकिन मेरे मामले में मुझे केवल डेटा परिवर्तनों को प्रबंधित करने की अपेक्षा है, जहां तक ​​डीबी आधारित फाइलस्टोर बदल सकता है, इसलिए मेरा समाधान शायद आपको वही नहीं हो सकता है जो आपको चाहिए।


मैं डेटाबेस को नियंत्रित करने वाले संस्करण के लिए neXtep की अनुशंसा करता neXtep , इसे दस्तावेज़ीकरण और मंचों का एक अच्छा सेट मिला है जो बताता है कि कैसे स्थापित करें और त्रुटियों का सामना करना पड़ा। मैंने postgreSQL 9.1 और 9.3 के लिए इसका परीक्षण किया है, मैं इसे 9.1 के लिए काम करने में सक्षम था लेकिन 9.3 के लिए यह काम नहीं कर रहा है।


मैं वास्तव में एक सरल समाधान के बारे में सोचना शुरू कर रहा हूं, मुझे नहीं पता कि मैंने इससे पहले क्यों नहीं सोचा था !!

  • डेटाबेस डुप्लिकेट करें, (स्कीमा और डेटा दोनों)।
  • नए-बड़े बदलावों के लिए शाखा में, नए डुप्लिकेट डेटाबेस का उपयोग करने के लिए बस प्रोजेक्ट कॉन्फ़िगरेशन को बदलें।

इस तरह मैं डेटाबेस स्कीमा परिवर्तनों के बारे में चिंता किए बिना शाखाएं स्विच कर सकता हूं।

संपादित करें:

डुप्लिकेट करके, मेरा मतलब है कि एक अलग डेटाबेस (जैसे my_db_2 ) के साथ एक और डेटाबेस बनाएं; डंप या ऐसा कुछ नहीं कर रहा है।


मैन्युअल रूप से अपने डीबी को डंप करने और इसे गिट में सहेजने के बजाय, ऑफस्केल डेटाग्रोव का उपयोग करें।

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

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


यहां मैं अपनी परियोजनाओं में क्या करने की कोशिश कर रहा हूं:

  • अलग डेटा और स्कीमा और डिफ़ॉल्ट डेटा।

डेटाबेस कॉन्फ़िगरेशन कॉन्फ़िगरेशन फ़ाइल में संग्रहीत है जो संस्करण नियंत्रण (.gitignore) के अंतर्गत नहीं है

डेटाबेस डिफ़ॉल्ट (नई परियोजनाओं को स्थापित करने के लिए) संस्करण नियंत्रण के तहत एक साधारण SQL फ़ाइल है।

डेटाबेस स्कीमा के लिए संस्करण नियंत्रण के तहत एक डेटाबेस स्कीमा डंप बनाएँ।

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

अन्य बड़ी ओपन सोर्स डेटाबेस प्रोजेक्ट्स (पिविक, या अपने पसंदीदा सीएमएस सिस्टम) पर एक नज़र डालें, वे सभी अपडेटस्क्रिप्ट (1. एसक्यूएल, 2. एसक्यूएल, 3. एसएस, 4. एफपी.5.sql) का उपयोग करते हैं।

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

तो सैद्धांतिक रूप से (और जो मैं खोज रहा हूं) आप प्रत्येक परिवर्तन के बाद डेटाबेस स्कीमा को छोड़ सकते हैं (मैन्युअल रूप से, conjob, गिट हुक (शायद प्रतिबद्ध होने से पहले)) (और केवल कुछ विशेष मामलों में अपडेटस्क्रिप्ट बनाते हैं)

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


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

प्रत्येक मशीन पर, हमारे पास PHP फ़ाइलें थीं, लेकिन MySQL सेवा भी थीं, और छवियों वाले फ़ोल्डर जो उपयोगकर्ता अपलोड करेंगे। लाइव सर्वर में कुछ 100K (!) आवर्ती उपयोगकर्ता होने लगे, डंप लगभग 2 जीबी (!) था, छवि फ़ोल्डर कुछ 50GB (!) था। जब तक मैंने छोड़ा, तब तक हमारा सर्वर अपने सीपीयू, राम, और सबसे अधिक, समवर्ती नेट कनेक्शन सीमाओं की सीमा तक पहुंच रहा था (हमने सर्वर कार्ड लॉकर को अधिकतम करने के लिए नेटवर्क कार्ड ड्राइवर का अपना संस्करण भी संकलित किया था)। हम जीआईटी में 2 जीबी डेटा और 50 जीबी छवियों को नहीं डाल सकते ( न ही आपको अपनी वेबसाइट के साथ मानना ​​चाहिए )।

जीआईटी के तहत यह सब आसानी से प्रबंधित करने के लिए, हम इन फ़ोल्डर पथों को .gitignore में डालने से बाइनरी फ़ोल्डरों (छवियों वाले फ़ोल्डर्स) को अनदेखा कर देंगे। हमारे पास Apache Documentroot पथ के बाहर SQL नामक फ़ोल्डर भी था। उस SQL ​​फ़ोल्डर में, हम डेवलपर्स से वृद्धिशील संख्याओं (001.florianm.sql, 001.johns.sql, 002.florianm.sql, आदि) में हमारी SQL फ़ाइलें डाल देंगे। इन एसक्यूएल फाइलों को भी जीआईटी द्वारा प्रबंधित किया गया था। पहली एसक्यूएल फ़ाइल में वास्तव में डीबी स्कीमा का एक बड़ा सेट होगा। हम जीआईटी में उपयोगकर्ता डेटा नहीं जोड़ते हैं (उदाहरण के लिए उपयोगकर्ता तालिका के रिकॉर्ड, या टिप्पणियां तालिका), लेकिन कॉन्फ़िगर या टोपोलॉजी या अन्य साइट विशिष्ट डेटा जैसे डेटा एसक्यूएल फाइलों (और इसलिए जीआईटी द्वारा) में बनाए रखा गया था। ज्यादातर इसके डेवलपर्स (जो कोड को सर्वश्रेष्ठ जानते हैं) जो निर्धारित करते हैं कि एसक्यूएल स्कीमा और डेटा के संबंध में जीआईटी द्वारा क्या और क्या नहीं रखा जाता है।

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

अगर परीक्षण सर्वर पर समस्याएं थीं, उदाहरण के लिए। विलयों में बहुत से संघर्ष थे, फिर कोड वापस कर दिया गया था (कार्यरत शाखा को 'लाइव' पर इंगित करना) और एसक्यूएल फाइलों को कभी निष्पादित नहीं किया गया था। जिस क्षण एसक्यूएल फाइलों को निष्पादित किया गया था, उस समय इसे एक गैर-परिवर्तनीय कार्रवाई के रूप में माना जाता था। यदि SQL फ़ाइलें ठीक से काम नहीं कर रही थीं, तो डीबी को डंप का उपयोग करके पुनर्स्थापित किया गया था (और डेवलपर्स ने बीमार परीक्षण वाली SQL फाइलें प्रदान करने के लिए कहा था)।

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

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


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





postgresql