क्या आप अपने डेटाबेस आइटम के लिए स्रोत नियंत्रण का उपयोग करते हैं? [बन्द है]

Question

मुझे लगता है कि मेरी दुकान में एक छेद है क्योंकि हमारे डेटाबेस स्कीमा में बदलाव के लिए हमारे पास ठोस प्रक्रिया नहीं है। हम बहुत सारे बैकअप करते हैं ताकि हम कम या ज्यादा कवर कर सकें, लेकिन इस तरह से आपकी रक्षा की अंतिम पंक्ति पर भरोसा करना बुरा है।

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

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

क्या इसके लिए कोई सर्वोत्तम प्रथाएं हैं? आपके लिए काम करने वाली कुछ रणनीतियाँ क्या हैं?

Comments

पॉडकास्ट 54 के अंत में चर्चा की गई। blog.stackoverflow.com/2009/05/podcast-54

— क्रिस मोसचिनी

Answer 1

अवश्य पढ़ें संस्करण नियंत्रण के तहत अपने डेटाबेस जाओ । के। स्कॉट एलन द्वारा पदों की श्रृंखला की जाँच करें।

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

Comments

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

— ulty4life

डेटाबेस के लिए एक वितरित संस्करण नियंत्रण प्रणाली है, जिसे क्लोनियो कहा जाता है जो डेटाबेस के लिए Git / GitHub की तरह है।

— अगस्त्य 23:

Answer 2

डेटाबेस खुद? नहीं

स्थिर डेटा आवेषण, संग्रहीत कार्यविधियाँ और इस तरह उन्हें बनाने वाली स्क्रिप्ट; बेशक। वे पाठ फ़ाइलें हैं, वे परियोजना में शामिल हैं और सब कुछ की तरह में और बाहर की जाँच कर रहे हैं।

एक आदर्श दुनिया में बेशक आपका डेटाबेस प्रबंधन उपकरण ऐसा करेगा; लेकिन आपको बस इसके बारे में अनुशासित होना होगा।

Comments

Mysql कार्यक्षेत्र के साथ आप एक संरचित फ़ाइल (xml) में वह सब रख सकते हैं जिसे GUI के साथ खोला और संभाला जा सकता है। Xml सिर्फ पाठ होने के नाते, हाँ यह एकल sql वाक्य टाइप किए बिना संस्करण हो सकता है।

— levhita

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

— त्रिंको

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

— शिव

मैं ध्यान देता हूँ कि चर्चा करने वाला शिव और ट्रिंकिन्को सामान्यतः "स्टेट-बेस्ड" बनाम "माइग्रेशन-आधारित" के रूप में बनाया गया है। यह एक बहुत विवादास्पद मुद्दा है और दोनों दृष्टिकोणों के पक्ष और विपक्ष हैं। मैं ध्यान दूंगा कि माइग्रेशन-आधारित दृष्टिकोण नवीनतम प्रवासियों के साथ डेटाबेस बनाने / बदलने / अपडेट करने के लिए तेजी से आगे बढ़ता है, जबकि एक राज्य-आधारित दृष्टिकोण वास्तव में परिवर्तन बनाता है। कौन सा दृष्टिकोण बेहतर है यह आंशिक रूप से इस बात पर निर्भर करता है कि क्या आप बार-बार डेटाबेस परिवर्तन (राज्य-आधारित का उपयोग करते हैं) या उत्पादन / परीक्षण / स्थानीय / CI (माइग्रेशन-आधारित का उपयोग करें) के लिए अक्सर तैनाती को प्राथमिकता देते हैं।

— ब्रायन

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

— ब्रायन

Answer 3

मैं पूरी तरह से सक्रिय ActiveRecord पलायन प्यार करता हूँ। यह डीएमएल को रूबी लिपि में सार करता है जो तब आपके स्रोत भंडार में आसानी से संस्करणबद्ध हो सकता है।

हालाँकि, थोड़े से काम से आप एक ही काम कर सकते हैं। कोई भी DDL परिवर्तन (परिवर्तन आदि) पाठ फ़ाइलों में संग्रहीत किया जा सकता है। फ़ाइल नामों के लिए एक नंबरिंग सिस्टम (या एक तारीख टिकट) रखें, और उन्हें क्रम में लागू करें।

रेल में डीबी में एक 'संस्करण' तालिका भी होती है जो अंतिम लागू प्रवास का ट्रैक रखती है। आप इसे आसानी से कर सकते हैं।

Comments

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

— अनातोली

Answer 4

स्रोत नियंत्रण का उपयोग करके डेटाबेस परिवर्तनों को प्रबंधित करने के लिए LiquiBase देखें ।

Comments

बस जोड़ने के लिए, फ्लाईवे एक प्रतिस्पर्धी उत्पाद है जो समान कार्यक्षमता प्रदान करता है जो अन्य स्टैकऑवरफ्लो थ्रेड्स पर भी अनुकूल उल्लेख प्राप्त करता है।

— स्टीव चैम्बर्स

Answer 5

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

if [ $VERSION \< '8.0.108' ] ; then
  psql -U cosuser $dbName << EOF8.0.108
    BEGIN TRANSACTION;
    --
    -- Remove foreign key that shouldn't have been there.
    -- PCR:35665
    --
    ALTER TABLE     migratorjobitems
    DROP CONSTRAINT migratorjobitems_destcmaid_fkey;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.108'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.108
fi

if [ $VERSION \< '8.0.109' ] ; then
  psql -U cosuser $dbName << EOF8.0.109
    BEGIN TRANSACTION;
    --
    -- I missed a couple of cases when I changed the legacy playlist
    -- from reporting showplaylistidnum to playlistidnum
    --
    ALTER TABLE     featureidrequestkdcs
    DROP CONSTRAINT featureidrequestkdcs_cosfeatureid_fkey;
    ALTER TABLE     featureidrequestkdcs
    ADD CONSTRAINT  featureidrequestkdcs_cosfeatureid_fkey
    FOREIGN KEY     (cosfeatureid)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    --
    ALTER TABLE     ticket_system_ids
    DROP CONSTRAINT ticket_system_ids_showplaylistidnum_fkey;
    ALTER TABLE     ticket_system_ids
    RENAME          showplaylistidnum
    TO              playlistidnum;
    ALTER TABLE     ticket_system_ids
    ADD CONSTRAINT  ticket_system_ids_playlistidnum_fkey
    FOREIGN KEY     (playlistidnum)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.109'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.109
fi

मुझे यकीन है कि ऐसा करने का एक बेहतर तरीका है, लेकिन यह अब तक मेरे लिए काम कर रहा है।

Comments

हम एक समान काम करते हैं सिवाय इसके कि हम प्रत्येक "अगर संस्करण" को एक अलग फाइल में रखें और एक उपकरण हो जो फाइलों को क्रम में चलाता हो।

— जवागल

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

— si618

मैंने भी लगभग ऐसा ही कुछ लिखा है, लेकिन जेट (जैसे एमएस एक्सेस) डेटबेस के लिए। हम वर्तमान में SQL सर्वर के लिए DB घोस्ट का उपयोग कर रहे हैं, जो आपके लिए बहुत कुछ करता है।

— केनी एविट

आप begin transaction; ... end transaction;पासिंग --single-transactionसे बदल सकते हैं psql।

— व्लादिमीर

Answer 6

हाँ। कोड है। मेरे अंगूठे का नियम यह है कि मुझे किसी विकास या उत्पादन मशीन को देखे बिना, खरोंच से एप्लिकेशन को बनाने और तैनात करने में सक्षम होना चाहिए ।

Answer 7

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

मेरा मानना ​​है कि यह NaNt / CruiseControl के साथ किया गया था।

Answer 8

हाँ, मुझे लगता है कि आपके डेटाबेस को संस्करण देना महत्वपूर्ण है। डेटा नहीं है, लेकिन कुछ के लिए स्कीमा।

रूबी ऑन रेल्स में, इसे "माइग्रेशन" के साथ ढांचे द्वारा नियंत्रित किया जाता है। जब भी आप db को बदलते हैं, आप एक स्क्रिप्ट बनाते हैं जो परिवर्तनों को लागू करती है और इसे स्रोत नियंत्रण में जाँचती है।

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

Answer 9

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

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

DB स्कीमा कई, कई छोटी .sql फ़ाइलों को बनाने के लिए "कटा हुआ" है, जो DDL कमांड के अनुसार एक है जो DB का वर्णन करता है।

+ टॉम

---

अतिरिक्त जानकारी 2008-11-30

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

क्योंकि स्कीमा को sql फाइलों में "श्रेड" किया जाता है, जिससे स्रोत नियंत्रण ठीक काम करता है।

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

VS DB प्रोजेक्ट, db परिवर्तनों को एकीकृत करने का एक अच्छा काम करता है जो अन्य टीम के सदस्यों ने आपके स्थानीय प्रोजेक्ट / संबद्ध db में किए हैं। लेकिन आपको अपने स्थानीय देव डीबी स्कीमा के साथ प्रोजेक्ट स्कीमा की तुलना करने और मॉड्स को लागू करने के लिए अतिरिक्त कदम उठाने की आवश्यकता है। यह समझ में आता है, लेकिन यह पहली बार में अजीब लगता है।

DB प्रोजेक्ट्स एक बहुत शक्तिशाली उपकरण है। वे न केवल स्क्रिप्ट उत्पन्न करते हैं, बल्कि उन्हें तुरंत लागू कर सकते हैं। सुनिश्चित करें कि इसके साथ अपने उत्पादन db को नष्ट न करें। ;)

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

+ टॉम

Answer 10

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

मैं ApexSQL सोर्स कंट्रोल नामक SSMS ऐड-इन का उपयोग करने का सुझाव दे सकता हूं । यह डेवलपर्स को एसएसएमएस से सीधे विज़ार्ड के माध्यम से स्रोत नियंत्रण प्रणाली के साथ डेटाबेस ऑब्जेक्ट को आसानी से मैप करने की अनुमति देता है। ऐड-इन में TFS, Git, तोड़फोड़ और अन्य SC प्रणालियों के लिए समर्थन शामिल है। इसमें स्टैटिक डेटा को नियंत्रित करने वाले स्रोत के लिए समर्थन भी शामिल है।

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

अधिक जानकारी के लिए आप इस लेख को पढ़ सकते हैं: http://solutioncenter.apexsql.com/sql-source-control-reduce-database-development-time/

Answer 11

मैं स्क्रिप्ट बनाने / अपडेट करने और एक स्क्रिप्ट को सहेज कर करता हूं जो कि नमूनाबद्धता उत्पन्न करता है।

Answer 12

हां, हम इसे अपने निर्माण के हिस्से के रूप में हमारे एसक्यूएल को रखकर करते हैं - हम DROP.sql, CREATE.sql, USERS.sql, VALUES.sql और वर्जन को नियंत्रित रखते हैं, इसलिए हम किसी भी टैग किए गए संस्करण पर वापस लौट सकते हैं।

हमारे पास चींटी कार्य भी हैं जो जब भी जरूरत हो db को फिर से बना सकते हैं।

साथ ही, SQL को तब आपके स्रोत कोड के साथ टैग किया जाता है जो इसके साथ जाता है।

Answer 13

सबसे सफल योजना जो मैंने कभी किसी परियोजना पर प्रयोग की है, में बैकअप और अंतर SQL फ़ाइलें संयुक्त हैं। मूल रूप से हम हर रिलीज़ के बाद अपने db का बैकअप लेते हैं और एक SQL डंप करते हैं ताकि हम स्क्रैच से एक खाली स्कीमा बना सकें, अगर हमें जरूरत हो। फिर कभी भी आपको DB में बदलाव करने की आवश्यकता होती है, आप संस्करण नियंत्रण के तहत sql निर्देशिका में एक परिवर्तनशील संख्या जोड़ देंगे। हम हमेशा फ़ाइल नाम के लिए एक क्रम संख्या या दिनांक को उपसर्ग करेंगे, इसलिए पहला परिवर्तन 01_add_created_on_column.sql की तरह होगा, और अगली स्क्रिप्ट 02_added_customers_index होगी। हमारी CI मशीन इनकी जांच करेगी और इन्हें बैकअप से बहाल किए गए db की एक नई प्रति पर क्रमिक रूप से चलाएगी।

हमारे पास कुछ स्क्रिप्ट भी थीं जो देवता अपने स्थानीय db को वर्तमान संस्करण में एकल कमांड के साथ पुनः आरंभ करने के लिए उपयोग कर सकते थे।

Answer 14

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

Answer 15

मैं अपने सभी डेटाबेस स्कीमा परिवर्तनों को नियंत्रित करने के लिए स्कीमाबैंक का उपयोग करता हूं:

• 1 दिन से, मैं अपने db स्कीमा डंप को इसमें आयात करता हूं
• मैंने वेब ब्राउज़र का उपयोग करके अपने स्कीमा डिज़ाइन को बदलना शुरू कर दिया (क्योंकि वे सास / क्लाउड-आधारित हैं)
• जब मैं अपने डीबी सर्वर को अपडेट करना चाहता हूं, तो मैं इसमें से परिवर्तन (एसक्यूएल) स्क्रिप्ट उत्पन्न करता हूं और डीबी पर लागू होता है। योजनाबैंक में, वे मुझे अद्यतन स्क्रिप्ट उत्पन्न करने से पहले एक संस्करण के रूप में अपना काम करने के लिए बाध्य करते हैं। मुझे इस तरह की प्रैक्टिस पसंद है ताकि जरूरत पड़ने पर मैं हमेशा वापस ट्रेस कर सकूं।

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

वैसे, उन्होंने हमें संस्करण नियंत्रण पेड़ के भीतर भी शाखाएं बनाने दीं ताकि मैं एक मंचन के लिए और एक उत्पादन के लिए रख सकूं। और सैंडबॉक्स कोडिंग के लिए एक।

संस्करण नियंत्रण एन परिवर्तन प्रबंधन के साथ एक बहुत साफ वेब आधारित स्कीमा डिजाइन उपकरण।

Answer 16

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

Answer 17

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

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

हां, आपके कहने से पहले, यह सामान रेल और दूसरों के समान है, लेकिन यह बहुत अच्छी तरह से काम करता है, इसलिए मुझे यह स्वीकार करने में कोई समस्या नहीं है कि मैंने बेशर्मी से विचार उठा लिया :)

Answer 18

मैं MySQL Workbech से निर्यात की गई SQL CREATE स्क्रिप्ट्स का उपयोग करता हूं, फिर उनकी "Export SQL ALTER" कार्यक्षमता का उपयोग करके मैं स्क्रिप्ट बनाने की एक श्रृंखला (निश्चित रूप से क्रमांकित) और उन स्क्रिप्ट्स को बदल सकता हूं जो उनके बीच बदलाव लागू कर सकते हैं।

3.- SQL SQL स्क्रिप्ट को निर्यात करें आम तौर पर आपको अपने द्वारा मॉडल में किए गए अपने परिवर्तनों को दर्शाते हुए, अब अपने हाथों से ALTER TABLE स्टेटमेंट लिखना होगा। लेकिन आप स्मार्ट हो सकते हैं और कार्यक्षेत्र को आपके लिए कड़ी मेहनत करने दें। बस मुख्य मेनू से फ़ाइल -> निर्यात -> फॉरवर्ड इंजीनियर SQL ALTER स्क्रिप्ट का चयन करें।

यह आपको SQL CREATE फ़ाइल निर्दिष्ट करने के लिए संकेत देगा, वर्तमान मॉडल की तुलना की जानी चाहिए।

चरण 1 से SQL बनाएँ स्क्रिप्ट का चयन करें। यह टूल आपके लिए ALTER TABLE स्क्रिप्ट उत्पन्न करेगा और आप इस स्क्रिप्ट को अपने डेटाबेस के विरुद्ध निष्पादित कर सकते हैं।

आप MySQL क्वेरी ब्राउज़र या mysql client.Voila का उपयोग करके ऐसा कर सकते हैं! आपका मॉडल और डेटाबेस अब सिंक्रनाइज़ हो गया है!

स्रोत: MySQL कार्यक्षेत्र सामुदायिक संस्करण: स्कीमा सिंक्रनाइज़ेशन के लिए गाइड

पाठ्यक्रम की यह सभी लिपियाँ संस्करण नियंत्रण के अंदर हैं।

Answer 19

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

Answer 20

डेटाबेस मॉडल के बारे में स्वयं बहुत चर्चा हुई है, लेकिन हम आवश्यक डेटा को .SQL फाइलों में भी रखते हैं।

उदाहरण के लिए, आपके एप्लिकेशन को उपयोगी होने के लिए इंस्टॉल में इसकी आवश्यकता हो सकती है:

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('AUD', 'Australian Dollars');

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('USD', 'US Dollars');

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

Comments

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

— करेन लोपेज

क्या यह व्यावहारिक है जब आप डेटाबेस में कई लाखों पंक्तियाँ हैं?

— रॉनी

Answer 21

हम अपने डेटाबेस के चारों ओर सब कुछ संस्करण और स्रोत नियंत्रित करते हैं:

• डीडीएल (बनाएं और अलर्ट)
• डीएमएल (संदर्भ डेटा, कोड, आदि)
• डेटा मॉडल परिवर्तन (ईआरविन या ईआर / स्टूडियो का उपयोग करके)
• डेटाबेस कॉन्फ़िगरेशन परिवर्तन (अनुमतियाँ, सुरक्षा ऑब्जेक्ट, सामान्य कॉन्फ़िगरेशन परिवर्तन)

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

Answer 22

मेरा मानना ​​है कि प्रत्येक डीबी को स्रोत नियंत्रण में होना चाहिए, और डेवलपर्स के पास खरोंच से अपने स्थानीय डेटाबेस बनाने का एक आसान तरीका होना चाहिए। डेटाबेस प्रोफेशनल के लिए विजुअल स्टूडियो से प्रेरित होकर, मैंने एक ओपन-सोर्स टूल बनाया है जो MS SQL डेटाबेस को स्क्रिप्ट करता है, और उन्हें आपके स्थानीय DB इंजन में तैनात करने का आसान और आसान तरीका प्रदान करता है। Http://dbsourcetools.codeplex.com/ आज़माएं । मज़ा आ गया, - नाथन।

Answer 23

यदि आपका डेटाबेस SQL ​​सर्वर है, तो हमारे पास सिर्फ वही समाधान हो सकता है जिसकी आप तलाश कर रहे हैं। SQL स्रोत नियंत्रण 1.0 अब जारी किया गया है।

http://www.red-gate.com/products/SQL_Source_Control/index.htm

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

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

Comments

मैं किसी के लिए रेड-गेट के उत्पाद की सिफारिश नहीं करूंगा। मैं कुछ समय से SQL सोर्स कंट्रोल 2.2 का उपयोग कर रहा हूं। वास्तव में जल्द ही उन्होंने संस्करण 3 जारी किया। इसके बाद उन्होंने 2.2 के लिए कोई समर्थन समाप्त कर दिया। यहां तक ​​कि उन्होंने कोई बग भी तय नहीं किया (जो मैं नई सुविधाओं पर विचार नहीं करता - कीड़े बग हैं), उन्होंने TFS2012 के लिए समर्थन भी शामिल नहीं किया था जब इसे जारी किया गया था। मेरी कंपनी TFS2010 से TFS2012 में बदल गई, और हम अब TFS से जुड़ नहीं सके। हमें शाब्दिक रूप से रेड गेट के सॉफ्टवेयर को फेंकना पड़ा, क्योंकि हमारे पास एकमात्र विकल्प था कि हम उनके सॉफ्टवेयर के नए संस्करण को खरीदें। कोई अद्यतन करने की योजना नहीं है। 2.2।

— दीमा

काश उनके पास गैर-Microsoft ऑपरेटिंग सिस्टम के लिए CLI समर्थन होता।

— 18

ऐसा लगता है कि उनके पास MySQL के लिए कुछ उपकरण हैं red-gate.com/products/mysql/mysql-comparison-bundle

— Jeff

Answer 24

मैं सभी ऑब्जेक्ट्स (तालिका परिभाषा, अनुक्रमित, संग्रहीत कार्यविधियाँ, आदि) को स्क्रिप्ट करके डेटाबेस स्कीमा को नियंत्रित करता हूं। लेकिन, डेटा के रूप में ही, बस नियमित रूप से बैकअप पर भरोसा करते हैं। यह सुनिश्चित करता है कि सभी संरचनात्मक परिवर्तन उचित संशोधन इतिहास के साथ कैप्चर किए गए हैं, लेकिन हर बार डेटा परिवर्तन के लिए डेटाबेस को बोझ नहीं करता है।

Answer 25

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

लाइव वातावरण में स्क्रिप्ट चलाने से पहले बहुत सारे परीक्षण किए जाते हैं, इसलिए "ओप्सिस" केवल तब होता है, आमतौर पर विकास डेटाबेस पर बोलते हैं।

Answer 26

हम सभी डेटाबेस को स्रोत नियंत्रण में ले जाने की प्रक्रिया में हैं। हम डेटाबेस के लिए स्क्रिप्ट बनाने के लिए sqlcompare का उपयोग कर रहे हैं (दुर्भाग्यवश एक व्यावसायिक संस्करण सुविधा), और उस परिणाम को SVN में डाल दिया।

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

आपको शुभकामनाएं, जितनी जल्दी आप इसे आजमाएंगे, उतनी ही जल्दी आप अपने मुद्दों को सुलझा लेंगे।

Answer 27

मैंने http://dbdeploy.com/ पर थॉटवर्क्स से dbdeploy टूल का उपयोग किया है । यह प्रवासन लिपियों के उपयोग को प्रोत्साहित करता है। प्रत्येक रिलीज़, हमने समझ को आसान बनाने और डीबीए को परिवर्तनों को 'आशीर्वाद' देने के लिए एक स्क्रिप्ट में परिवर्तन स्क्रिप्ट को समेकित किया।

Answer 28

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

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

एक उत्कृष्ट उपकरण। यहाँ लिंक है: http://www.sqldelta.com/

Answer 29

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

RedGate डेटा स्नैपशॉट भी बनाता है, जबकि मैंने व्यक्तिगत रूप से उनके साथ काम नहीं किया है, वे उतने ही मजबूत हैं।

Comments

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

— डेविड एटकिंसन

Answer 30

FYI करें यह भी कुछ दिनों पहले दाना द्वारा लाया गया था ... स्रोत नियंत्रण में संग्रहीत कार्यविधियाँ / DB स्कीमा