sql यवस डेटाबेस संरचना परिवर्तन के लिए एक संस्करण नियंत्रण प्रणाली है?




संबंधपरक डेटाबेस प्रबंधन प्रणाली (18)

दो पुस्तक अनुशंसाएं: एम्बलर और सदालेज द्वारा "रिफैक्टरिंग डेटाबेस" और एम्बलर द्वारा "एग्इल डाटाबेस टेक्निक्स"।

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

मैं अक्सर निम्नलिखित समस्या में भाग लेता हूं।

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

इसलिए, मैं लाइव सिस्टम को धक्का देता हूं और एक बड़ी, स्पष्ट त्रुटि प्राप्त करता NewColumnX कि कोई NewColumnX नहीं है, ओह।

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


Redgate में SQL स्रोत नियंत्रण नामक एक उत्पाद है। यह टीएफएस, एसवीएन, सोर्सगियर वॉल्ट, वॉल्ट प्रो, मर्कुरियल, पर्सफोर्स और गिट के साथ एकीकृत करता है।


रेल पर रूबी में, migration की एक अवधारणा है - डेटाबेस को बदलने के लिए एक त्वरित स्क्रिप्ट।

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

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

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


ओरेकल पैकेज डीबीएमएस_एमटीएडीएटीएए पर एक नज़र डालें।

विशेष रूप से, निम्नलिखित विधियां विशेष रूप से उपयोगी होती हैं:

  • DBMS_METADATA.GET_DDL
  • DBMS_METADATA.SET_TRANSFORM_PARAM
  • DBMS_METADATA.GET_GRANTED_DDL

एक बार जब आप परिचित होते हैं कि वे कैसे काम करते हैं (सुंदर आत्म व्याख्यात्मक) आप उन विधियों के परिणामों को उन स्रोत फ़ाइलों में डंप करने के लिए एक साधारण स्क्रिप्ट लिख सकते हैं जिन्हें स्रोत नियंत्रण में रखा जा सकता है। सौभाग्य!

सुनिश्चित नहीं है कि MSSQL के लिए यह कुछ आसान है या नहीं।


मैं थोड़ा पुराना स्कूल हूं, जिसमें मैं डेटाबेस बनाने के लिए स्रोत फ़ाइलों का उपयोग करता हूं। वास्तव में 2 फाइलें हैं - प्रोजेक्ट-डेटाबेस.sql और project-update.sql - स्कीमा और लगातार डेटा के लिए पहला, और संशोधन के लिए दूसरा। बेशक, दोनों स्रोत नियंत्रण में हैं।

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

इसके अलावा, मेरे पास आमतौर पर डीबी - कॉन्फ़िगर में एक सारणी होती है - जैसे कि:

एसक्यूएल

CREATE TABLE Config
(
    cfg_tag VARCHAR(50),
    cfg_value VARCHAR(100)
);

INSERT INTO Config(cfg_tag, cfg_value) VALUES
( 'db_version', '$Revision: $'),
( 'db_revision', '$Revision: $');

फिर, मैं अद्यतन खंड में निम्नलिखित जोड़ता हूं:

UPDATE Config SET cfg_value='$Revision: $' WHERE cfg_tag='db_revision';

db_version केवल तब बदल जाता है जब डेटाबेस पुनर्निर्मित होता है, और db_revision मुझे संकेत देता है कि डीबी बेसलाइन से कितनी दूर है।

मैं अद्यतनों को अपनी अलग फाइलों में रख सकता था, लेकिन मैंने उन सभी को एक साथ मैश करना चुना और प्रासंगिक अनुभाग निकालने के लिए कट और पेस्ट का उपयोग किया। थोड़ा और हाउसकीपिंग क्रम में है, यानी, $ 1.1 से $: $ को निकालने के लिए उन्हें हटाएं।


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

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


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

यह कहना उचित है कि यह संस्करण 1.0 उत्पाद है, हालांकि, और कुछ मुद्दों के बिना नहीं है।


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

http://www.red-gate.com/Products/schema_compare_for_oracle/index.htm


मैं अत्यधिक एसक्यूएल डेल्टा की सलाह देते हैं। जब मैं अपनी सुविधा को कोडिंग करता हूं और उन स्क्रिप्ट को अपने स्रोत नियंत्रण उपकरण (Mercurial :)) में जांचता हूं तो मैं बस diff स्क्रिप्ट उत्पन्न करने के लिए इसका उपयोग करता हूं।

उनके पास एक SQL सर्वर और ओरेकल संस्करण दोनों हैं।


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

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


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

एमएसडीएन पर एक निर्देशक video है जो बहुत उपयोगी है।

मुझे डीबीएमएस_एमटीएडीएटीए और टॉड के बारे में पता है, लेकिन अगर कोई ओरेकल के लिए डेटा डुड के साथ आ सकता है तो जीवन वास्तव में मीठा होगा।


ईआर स्टूडियो आपको टूल में अपनी डेटाबेस स्कीमा को रिवर्स करने की अनुमति देता है और फिर आप इसे लाइव डेटाबेस में तुलना कर सकते हैं।

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

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


Ruckusing नामक एक PHP5 "डेटाबेस माइग्रेशन फ्रेमवर्क" है। मैंने इसका उपयोग नहीं किया है, लेकिन examples इस विचार को दिखाते हैं, यदि आप आवश्यकतानुसार डेटाबेस बनाने के लिए भाषा का उपयोग करते हैं, तो आपको केवल स्रोत फ़ाइलों को ट्रैक करना होगा।


MyBatis (पूर्व में iBatis) में स्कीमा माइग्रेशन , कमांड लाइन पर उपयोग के लिए उपकरण है। यह जावा में लिखा गया है हालांकि किसी भी परियोजना के साथ इस्तेमाल किया जा सकता है।

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

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

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


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


तालिका परिवर्तनों के लिए वीसीएस की अनुपस्थिति में मैं उन्हें विकी में लॉगिंग कर रहा हूं। कम से कम तब मैं देख सकता हूं कि यह कब और क्यों बदला गया था। यह बिल्कुल सही नहीं है क्योंकि हर कोई ऐसा नहीं कर रहा है और हमारे पास उपयोग में कई उत्पाद संस्करण हैं, लेकिन कुछ भी नहीं है।


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





version-control