7

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

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

तो मेरा सवाल यह है कि, क्या आप किसी भी अच्छी सलाह के बारे में जानते हैं जो मैं अपने डीबीए को पास कर सकता हूं और यहां तक ​​कि कुछ संसाधन भी बताते हैं कि आप डीबी स्कीमा को स्रोत नियंत्रण में रखने के लिए कैसे जाएंगे और इसकी उचित जगह ढूंढें निर्माण और तैनाती प्रक्रियाओं में?

पर्यावरण के बारे में तथ्यों के एक जोड़े: एक TFS 2008 सर्वर पर

  • स्रोत नियंत्रण।
  • डेटाबेस एक एमएस एसक्यूएल सर्वर 2008 है> 300 टेबल और> 300 अन्य ऑब्जेक्ट्स (स्पॉक्स, ट्रिगर्स, फ़ंक्शंस इत्यादि)।

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

+0

मैं अभी तक स्रोत नियंत्रण में एसक्यूएल सर्वर वस्तुओं को पाने के लिए किसी भी आसान तरीका देखने के लिए है। यह हमेशा आपके एचडीडी पर स्क्रिप्ट से काम करने की झुकाव है। फिर कुछ Putz हमेशा जा सकते हैं, उस संग्रहित proc पर "संशोधित" हिट, और दूर वे जाते हैं। इसलिए, यदि कोई बेहतर तरीका है (टीएम) तो मुझे रूचि है। – Eric

+2

स्पष्टीकरण को देखते हुए ऐसा लगता है कि आपके पास "तकनीकी" समस्या नहीं है बल्कि "लोगों" समस्या है। कोई भी सही उपकरण उसके दिमाग को बदलने के लिए नहीं जा रहा है कि वह अपना काम कैसे करता है। एक उच्च अधिकार के माध्यम से उसे निर्धारित करने की आवश्यकता के मामले की तरह लगता है। –

+0

आप शायद सही हैं। – JohannesH

उत्तर

4

, how to version control sql server databases और Do you source control your databases देखें कई अन्य लोगों के अलावा। या searchpage का उपयोग करें। असल में, आपका दृष्टिकोण सही लगता है। गुड लक डीबीए राजी ...

+0

धन्यवाद, मैं अपना सर्वश्रेष्ठ प्रदर्शन करूंगा। – JohannesH

0

आप वास्तव में स्रोत नियंत्रण के तहत एक बड़ा डेटाबेस नहीं डाल सकते हैं, इसलिए आपका डीबीए सही है।

व्यावहारिक रूप से आप क्या कर सकते हैं अपने स्कीमा को स्रोत नियंत्रण के तहत रखना, और शायद कुछ छोटी 'कॉन्फ़िगरेशन' तालिकाएं।

+0

मेरा मतलब स्कीमा था ... क्षमा करें मैं स्पष्ट करूंगा। – JohannesH

+0

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

2

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

+0

मुझे लगता है कि हम सहमत हैं ... आपको लगता है कि मेरे प्रिय डीबीए को वीएस डीबी संस्करण जैसे टूल पर कूदना चाहिए। लेकिन वह नहीं है। – JohannesH

1

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

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

सामान्य रूप से, यह डेटाबेस स्रोत नियंत्रण विकल्प के रूप में काफी ठोस है।

+0

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

+0

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

+0

दुर्भाग्य से वह इसे अपना रास्ता संभालने में बहुत अच्छा नहीं है। अगर वह था तो वह अपना काम नहीं खोलेगा। ;) और इससे भी बदतर यह पहली बार नहीं है कि उनके विकास "प्रक्रिया" ने समस्याएं पैदा की हैं।मेरी समस्या यह है कि मेरे पास उस लड़के पर कोई शक्ति नहीं है, इसलिए मैं जो कुछ भी कर सकता हूं वह उसे साक्ष्य देने के साथ प्रस्तुत करता है कि उसे अपने दुष्ट तरीकों को बदलना चाहिए। – JohannesH

0

एक तरह से स्रोत के लिए नियंत्रण डेटाबेस में और डेटाबेस के बारे में डेटा स्टोर अलग

  1. आप सभी तालिकाओं, प्रक्रियाओं और एसक्यूएल फ़ाइलों के रूप में समारोह स्क्रिप्ट हो सकता है और स्रोत नियंत्रण करने के लिए उन्हें जोड़ने के लिए है।

  2. निर्यात एसक्यूएल फ़ाइलों में डालने बयान, एक निश्चित आकार के साथ प्रत्येक के रूप में डेटाबेस डेटा। यह एक बोझिल प्रक्रिया है क्योंकि इसमें बहुत सी फाइलें शामिल होंगी जिन्हें ट्रैक और नियंत्रित किया जाना चाहिए।

  3. मुझे यकीन है कि अगर वीएसएस/SVN परिवर्तन के पढ़ सकते हैं और इतिहास रखने के लिए डेटाबेस बैकअप विकल्प द्वारा बनाई गई फ़ाइलों डंप करने में सक्षम हैं नहीं कर रहा हूँ।

0

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

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

(और मैं वीएसएस के बारे में सोचना कंपकंपी एसक्यूएल प्रबंधन स्टूडियो में एकीकृत: - (()

+0

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

+0

@ जोहान्स आपकी स्पष्टीकरण के बाद मुख्य प्रश्न पर मेरी टिप्पणी के अनुसार, तकनीक टूटी नहीं है, आपका डीबीए है! –

1
डेटाबेस के लिए

स्रोत नियंत्रण काफी विवादास्पद हो सकता है यह कुछ है कि एक द्विआधारी उत्पादन के लिए स्रोत नियंत्रण का उपयोग करने के अलग अलग है, क्योंकि आप कर सकते हैं। स्रोत को लॉक नहीं करें: एक संग्रहित proc एक तालिका में एक पंक्ति है और तालिका परिभाषा प्राप्त करने के लिए पढ़ने के लिए एकल तालिका नहीं है।

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

मेरे लिए

, यह एक प्रक्रियात्मक त्रुटि है।

स्क्रिप्ट से परिवर्तन क्यों नहीं किया गया था? भूल जाओ कि स्क्रिप्ट कहाँ रहती है, लेकिन क्यों कोई पुन: उत्पन्न करने योग्य और पुनः चलाने योग्य स्क्रिप्ट नहीं? शायद परिवर्तन ट्रैकिंग नंबर से जुड़ा हुआ है? यदि डेटाबेस रीसेट (प्रोड से लोड किया गया है) तो उत्पादन के लिए तैयार करने के लिए परिवर्तन को फिर से लागू किया जाएगा। और अन्य प्रश्न।

मैं स्रोत नियंत्रण में विश्वास करते हैं और हम इसे का उपयोग करें: लेकिन यह डेटाबेस काम के लिए सीमा नहीं है।

+0

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

+0

हम खाली निर्माण के बजाय उत्पादन की एक प्रति के खिलाफ काम करते हैं: हम यथार्थवादी डेटा – gbn

+0

के खिलाफ कोड काम सुनिश्चित करना चाहते हैं ... और यह आपके लिए एक लोगों/प्रक्रिया मुद्दे है, मुझे लगता है कि – gbn

1

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

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

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

0

इस एक ही समस्या के लिए मेरा जवाब पाठ के रूप (एक से अधिक उनमें से 136,000) के लिए सभी डीबी वस्तुओं का निर्यात करने और फिर उन्हें पकड़ करने के लिए SourceSafe परियोजनाएं बनाने था। डीबी में कोई नई या बदली हुई वस्तुएं अब सोर्ससेफ संरचना पर जाती हैं, जबकि अपरिवर्तित अकेले रह जाते हैं।

1

एसक्यूएल के लिए उत्पाद प्रबंधक के रूप में मैंने कई 'पारंपरिक DBAs जो तीसरे पक्ष के उपकरणों के साथ असहज मुख्य रूप से है क्योंकि वे एक प्रणाली है कि उनके लिए और कभी कभी बदल रहा है मुश्किल हो सकता है काम करता है कर रहे हैं करने के लिए बात की है की तुलना करें। ऐसी कई स्थितियां हैं जहां मुझे आश्वस्त किया जाता है कि अगर वे केवल उन्हें मौका देते हैं तो उन्हें हमारे उपकरण से फायदा होगा। निराशा होती।

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

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

+0

बस यह घोषणा करने के लिए कि अब इसे जारी कर दिया गया है और मूल्यांकन और खरीद के लिए उपलब्ध है। http://www.red-gate.com/products/SQL_Source_Control/index.htm –

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