मैंने इस सवाल को स्टैक ओवरफ्लो पर खोजने की कोशिश की है, लेकिन इसके लिए कोई सवाल नहीं खोज सका।
मैं नया हूं Liquibaseऔर जानना चाहता हूं
Liquibase?Liquibaseपरियोजना में उपयोग करना चाहिए ?मुझे पता है कि यह सभी डेटाबेस परिवर्तनों को एक स्थान पर रखना है लेकिन SQLकुछ रिपॉजिटरी सिस्टम में एक साधारण फाइल बनाकर इसी तरह किया जा सकता है और इसे समय के साथ अपडेट करते रहना चाहिए।
जवाबों:
एक स्व-प्रबंधित स्कीमा और फ़ाइलबिज़ (या अन्य स्कीमा माइग्रेशन टूल) के बीच महत्वपूर्ण अंतर यह है कि उत्तरार्द्ध एक स्कीमा चैंज को प्रदान करता है। यह समय के साथ स्कीमा परिवर्तन का एक रिकॉर्ड है। यह डेटाबेस डिजाइनर को स्कीमा में परिवर्तन को निर्दिष्ट करने की अनुमति देता है और मांग पर स्कीमा के क्रमिक उन्नयन या डाउनग्रेड को सक्षम करता है।
अन्य लाभ हैं, जैसे:
एक वैकल्पिक उपकरण फ्लाईवे है ।
जब आप डेटा खोए बिना स्कीमा अपडेट को स्वचालित रूप से प्रबंधित करना चाहते हैं, तो आपको स्कीमा माइग्रेशन टूल का उपयोग करना होगा। यही है, आप उम्मीद करते हैं कि आपके सिस्टम को ग्राहक साइट या स्थिर परीक्षण वातावरण जैसे लंबे समय तक रहने वाले वातावरण में तैनात किए जाने के बाद स्कीमा में बदलाव होगा।
जब स्कीमा को संशोधित करने की बात आती है तो मैंने डेवलपर्स के बीच डिसाइड डिसिप्लिन बनाया है। आप बस नहीं जा सकते हैं और अन्य डेवलपर के परिवर्तन को अधिलेखित और निष्पादित कर सकते हैं। इसके बजाय, आप अपना स्वयं का बदलाव करते हैं और इसे निष्पादित किए जाने वाले परिवर्तनों के अनुक्रम के अंत में जोड़ते हैं। यह भी स्पष्टता लाता है कि कब और किसने क्या परिवर्तन लाया।
स्कीमा बनाए रखने के लिए एक बहुत ही "संस्करण" दृष्टिकोण।
शुरुआत के लिए, यह "अनावश्यक काम" की छाप देता है।
मेरा मानना है कि लिक्विबेस महान है जब आपका दर्शन है कि डेटाबेस एक बाद है। इस दर्शन ने उत्पादन में अधिकांश खराब डेटाबेस का कारण बना है - और उनमें से अधिकांश खराब हैं। एक डेटाबेस को पूरे व्यापार प्रणाली के एक पूर्ण दृष्टिकोण के साथ डिज़ाइन किया जाना चाहिए, न कि अनुप्रयोग डेवलपर्स द्वारा प्रत्येक अपने स्वयं के साइलो में काम करने के लिए। उत्तरार्द्ध विधि का परिणाम काम-आस-पास, विकृत डेटा, तालिकाओं के बीच खराब संबंध, व्यावसायिक क्षेत्रों का दोहराव और एक समग्र गड़बड़, उच्च रखरखाव-लागत प्रणाली है जो क्लाइंट को समस्याओं के कारण तैनाती के तुरंत बाद घृणा करेगा। यदि डेटाबेस को ACCURATELY के लिए डिज़ाइन किया गया है जो व्यावसायिक संबंधों को प्रतिबिंबित करता है, तो इसका जीवनकाल 5 गुना लंबा होगा और अपने उद्देश्य को 5 गुना बेहतर तरीके से पूरा करेगा जो एक टुकड़ों में फैशन में डिज़ाइन किए गए दुर्भाग्य से सबसे अधिक हैं।
लिक्विबेस अपने आप में कोई समस्या नहीं है, लेकिन यह उस प्रैक्टिस को सक्षम बनाता है जो एप्लिकेशन डेवलपर्स डेटाबेस को डिजाइन करता है। यही दिक्कत है।
मुझे लगता है कि अगर आप नीचे दिए गए लेख http://shengwangi.blogspot.com/2016/04/liquibase-helloworld-example.html पर जाते हैं, तो शराबबंदी का जवाब क्यों दिया जा सकता है
यदि आप इसे ध्यान से पढ़ते हैं तो सरल mvn या CLI कमांड की मदद से उच्च संस्करण से निचले संस्करण में डाउनग्रेड करने की क्षमता बहुत उपयोगी है, जो आपको GIT में अपनी sql फाइल करने के दृष्टिकोण से गुजरने पर नहीं मिलती है क्योंकि तब आप मैन्युअल रूप से उन लिपियों को चलाना होगा और आपके पास परिवर्तन सेट भी नहीं होना चाहिए: - जिन्होंने लेखक को बदल दिया, आदि।
मेरी टीम के DevOps व्यक्ति होने के नाते मैं अपनी सभी SQL फ़ाइलें एक स्थान पर अर्थात मेरे SCM (स्रोत कोड प्रबंधन) में रखना पसंद करूंगा
इसके अलावा CI / CD चरण के दौरान , यदि DB स्कीमा इसके साथ बनाई जाती है, तो यह बहुत समय और संसाधन बचाता है। आपको उस क्लाइंट के लिए अपने डेटाबेस को प्रबंधित करने वाला कोई दूसरा व्यक्ति नहीं होना चाहिए।
ORM जैसे फ्लाईवे, लिक्विबेस, EF आदि इसे प्राप्त करने में मदद करता है।