डाटाबेस परिनियोजन सर्वोत्तम प्रथाओं

Question

अधिकतर हम सॉफ्टवेयर उन्नयन/बगफिक्स के लिए तालिका में मौजूदा डेटाबेस टेबल, संग्रहित प्रक्रियाओं, कार्यों या पैरामीटर को बदलते हैं। और जब उत्पादन या प्रजनन जैसे किसी अन्य वातावरण में हमारे परिवर्तनों को तैनात करने का समय है, तो हमारे डीबी परिवर्तनों के कुछ हिस्सों को भुला दिया जाता है।

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

मुझे आश्चर्य है कि आप उत्पादन वातावरण में डीबी परिवर्तनों को तैनात करने के लिए क्या कर रहे हैं। आप इस तरह क्यों चुनते हैं? या क्या किया जाना चाहिए?

उत्तर के लिए धन्यवाद!

Answer 1

हमारे पास स्रोत नियंत्रण के तहत हमारा डीबी है। किसी भी बदलाव को इस तरह से ट्रैक किया जाता है। और कुछ भी एक दुःस्वप्न होगा। http://www.codeplex.com/sqlhost/Wiki/View.aspx?title=Database%20Publishing%20Wizard - - http://blog.codinghorror.com/get-your-database-under-version-control/

अपने सेटअप और डेटाबेस, डेटाबेस प्रकाशन विज़ार्ड के आधार पर

- वास्तव में उपयोगी हो सकता है

जेफ भी इस पर एक लेख है।

Answer 2

एसक्यूएल में किए गए हर बदलाव को स्क्रिप्टिंग और संग्रह करना आईएमओ का सबसे अच्छा तरीका है।

Answer 3

एक परियोजना में, मेरे पास डीडीएल स्क्रिप्ट में मेरे सभी डीबी परिवर्तन हैं। उन स्क्रिप्ट में SQL कथन शामिल होते हैं जो डीबी को एक निश्चित संस्करण में अपग्रेड करने के लिए आवश्यक होते हैं। स्क्रिप्ट के फ़ाइल नाम में डीबी का संस्करण-संख्या भी शामिल है जिसमें डीबी को अपग्रेड किया जाएगा (_versionnumber.sql)

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

नई परियोजनाओं के लिए, अब मैं Migrator.NET का उपयोग करता हूं। यह ढांचा आपको सी # कक्षाओं में अपने डीबी परिवर्तन लिखने देता है। ढांचे में एक कंसोल एप्लिकेशन होता है जिसके साथ आप डीबी परिवर्तन निष्पादित कर सकते हैं, और एमएसबिल्ड के साथ इसका उपयोग करना भी संभव है।

Answer 4

प्रत्येक डेटाबेस ऑब्जेक्ट को संस्करण नियंत्रण प्रणाली में एक अलग फ़ाइल में संग्रहीत किया जाएगा। संस्करण नियंत्रण प्रणाली इस उदाहरण की तरह फ़ाइलें हो सकता है:

|- tables 
    |- employees.sql 
    |- contracts.sql 
|- packages 
    |- contract_api.sql 
|- functions 
    |- get_employee_name.sql 
...etc... 

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

लेकिन, जैसा कि आप जानते हैं, डीडीएल स्क्रिप्ट हैं, जिन्हें दो बार निष्पादित नहीं किया जा सकता है। उदाहरण के लिए 'टेबल mytable बनाएं ...' स्क्रिप्ट केवल एक बार निष्पादित की जा सकती है। और यदि आपका सिस्टम पहले से ही उत्पादन में है, तो आप अपने 'CREATE टेबल ...' स्क्रिप्ट के शीर्षलेख में 'ड्रॉप टेबल mytable' कथन बर्दाश्त नहीं कर सकते हैं। इसलिए उत्पादन प्रणालियों के लिए आपको डेल्टा स्क्रिप्ट बनाने की आवश्यकता है जो केवल परिवर्तन प्रदान करेगी। इस मामले में आप आसानी से staff_upd01.sql नामक एक नई फ़ाइल बना सकते हैं जिसमें 'वैकल्पिक तालिका mytable जोड़ें COLUMN' कथन शामिल है।

कुछ समय के बाद अपने भंडार ऐसा दिखाई दे सकता:

|- tables 
    |- employees.sql 
    |- employees_upgr20091001.sql 
    |- employees_upgr20091004.sql 
    |- contracts.sql 
|- packages 
    |- contract_api.sql 
|- functions 
    |- get_employee_name.sql 
...etc... 

और यह ठीक है, क्योंकि: 1) जब आप डेटाबेस के लिए आज 'वृद्धिशील परिवर्तन वितरित करने के लिए की जरूरत है - आप फ़ाइलों को संशोधित किया गया आज तैनात 2) यदि आपको अपने सिस्टम की क्लीन स्थापना को तैनात करने की आवश्यकता है - तो आप क्रम में सभी स्क्रिप्ट चलाते हैं, उदाहरण के लिए पहले employees.sql, तो employees_upgr20091001.sql, आदि

प्रत्येक डीबी वस्तु संस्करण नियंत्रण प्रणाली में एक अलग फाइल में है के रूप में, आप सभी परिवर्तनों पर एक अच्छा नियंत्रण है।