2008-12-09 8 views
22

हम अपनी अधिकांश परियोजनाओं पर SQL Server 2000/2005 और वॉल्ट या एसवीएन का उपयोग करते हैं। मुझे स्रोत नियंत्रण प्रणाली में डेटाबेस स्कीमा/प्रो परिवर्तनों को कैप्चर करने के लिए एक सभ्य समाधान नहीं मिला है।आप स्रोत नियंत्रण में डेटाबेस परिवर्तनों को कैसे ट्रैक करते हैं?

हमारा वर्तमान समाधान काफी बोझिल और लागू करने में मुश्किल है (आपके द्वारा परिवर्तित ऑब्जेक्ट को स्क्रिप्ट करें और इसे डेटाबेस में प्रतिबद्ध करें)।

हमारे पास कुछ कस्टम विकास के साथ इस समस्या से निपटने के तरीके के बारे में बहुत सारे विचार हैं, लेकिन मैं एक मौजूदा उपकरण स्थापित करना चाहता हूं (भुगतान उपकरण ठीक हैं)।

तो: आप अपने डेटाबेस कोड में परिवर्तन कैसे ट्रैक करते हैं? क्या आपके पास कोई अनुशंसित उपकरण है?


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

सभी सुझावों के लिए धन्यवाद। समय की बाधाओं के कारण, मैं यहां अपना खुद का रोल नहीं करना चाहूंगा। और अधिकांश सुझावों में यह दोष है कि उन्हें कुछ प्रक्रिया का पालन करने के लिए देव की आवश्यकता होती है।

इसके बजाय, एक आदर्श समाधान एसक्यूएल में परिवर्तन के लिए एसक्यूएल डाटाबेस की निगरानी करेगा और एससीएम में किसी भी ज्ञात परिवर्तन को करेगा। उदाहरण के लिए, यदि SQL सर्वर में एक ऐड-ऑन था जो उस उपयोगकर्ता के साथ किसी भी डीएमएल परिवर्तन को रिकॉर्ड कर सकता है जिसने परिवर्तन किया है, तो उस ऑब्जेक्ट की स्क्रिप्ट को एससीएम पर प्रतिबद्ध करें, मैं रोमांचित होगा।

हमने आंतरिक रूप से दो प्रणालियों के बारे में बात की: 1. SQL 2005 में, किसी ऑब्जेक्ट को बदलने से प्रतिबंधित करने के लिए ऑब्जेक्ट अनुमतियों का उपयोग करें जब तक कि आपने "चेकआउट" नहीं किया हो। फिर, चेकइन प्रक्रिया इसे एससीएम में लिपिगी। 2. किसी भी परिवर्तन का पता लगाने के लिए एक निर्धारित नौकरी चलाएं और उन्हें (अनामिक रूप से) एससीएम को प्रतिबद्ध करें।

यह अच्छा होगा अगर मैं उपयोगकर्ता-क्रिया भाग को छोड़ सकता हूं और सिस्टम को यह सब स्वचालित रूप से संभाल सकता है।

उत्तर

15

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

http://www.vitalygorn.com/blog/post/2008/01/Handling-Database-easily-with-Visual-Studio-2008.aspx

में यहाँ उन पर नज़र डालें या आधिकारिक दस्तावेज के लिए MSDN की जाँच

3

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

+0

मुझे यह दृष्टिकोण भी पसंद है। –

1

मैं सिर्फ SQL-Alter-स्टेटमेंट को पूर्ण SQL-CreateDB-statement में अतिरिक्त प्रतिबद्ध करता हूं।

1

SQL2000 में प्रत्येक वस्तु को उसकी अपनी फ़ाइल में है, तो उत्पन्न उन सब को अपने स्रोत नियंत्रण में जाँच । अपने स्रोत नियंत्रण को परिवर्तन इतिहास को संभालने दें।

SQL 2005 में, आपको सभी ऑब्जेक्ट्स को अलग-अलग फ़ाइलों में उत्पन्न करने के लिए थोड़ा कोड लिखना होगा।

+0

इस उत्तर के साथ कुछ भी गलत नहीं है, लेकिन आप फ़ाइलों को मैन्युअल रूप से उत्पन्न करने वाले घंटों की संख्या को मापने पर विचार कर सकते हैं और उस प्रक्रिया को स्वचालित करने के लिए किसी टूल की खरीद को उचित ठहराने में सहायता के लिए कुल लागत के साथ आते हैं। :) – Mayo

5

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

मुझे अपनी तालिका में प्रत्येक टेबल, प्रो और फ़ंक्शन पसंद है।

+0

+1, धन्यवाद! टीटी ने आपको इस जवाब में हरा दिया, इसलिए मैंने इसे स्वीकार कर लिया। –

0

हमारे डीबीए समय-समय पर एसवीएन में जो कुछ है उसके खिलाफ प्रोड की जांच करते हैं और किसी भी ऑब्जेक्ट को स्रोत नियंत्रण में नहीं हटाते हैं। यह केवल एक बार लेता है जब devlopers फिर से स्रोत नियंत्रण में कुछ डालना भूल जाते हैं।

हम किसी को स्क्रिप्ट के बिना प्रोडक्ट्स को प्रोडक्ट करने की इजाजत नहीं देते हैं क्योंकि हमारे देवताओं के पास प्रोड अधिकार नहीं हैं, यह लागू करना आसान है।

1

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

1

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

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

0

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

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

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

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

+0

यह तब तक काम करता है जब तक आपके पास डेटा से भरा बड़ा डेटाबेस न हो और आपको स्कीमा को बदलना पड़े। –

0

यदि आप उपयोग कर रहे हैं।नेट और दृष्टिकोण की तरह रेल माइग्रेशन के साथ लेता है, तो मैं Migrator.Net की सिफारिश करता हूं।

मुझे nice tutorial मिला जो विजुअल स्टूडियो में इसे स्थापित करने के माध्यम से चलता है। वह संदर्भ के लिए एक नमूना परियोजना भी प्रदान करता है।

0

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

हालांकि इस तरह का समाधान ज्यादातर परियोजनाओं के लिए निश्चित रूप से अधिक है, यह निश्चित रूप से कई बार जीवन को आसान बनाता है।

0

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

3

ट्रैकिंग डेटाबेस की एक बहुत हैं SSMS से सीधे बदल जाता है विभिन्न 3 पार्टी उपकरण का उपयोग कर सकता है। ApexSQL Source Control स्वचालित रूप से किसी भी डेटाबेस ऑब्जेक्ट को स्क्रिप्ट करता है जो संस्करण में शामिल है। उपकरण स्वचालित रूप से उपकरण द्वारा नहीं किया जा सकता है। इसके बजाए, उपयोगकर्ता को यह चुनने की जरूरत है कि कौन से परिवर्तन किए जाएंगे।

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

संबंधित मुद्दे