आपको स्रोत नियंत्रण से अपने डेटाबेस का निर्माण कैसे करना चाहिए?

Question

डेटाबेस ऑब्जेक्ट्स को नियंत्रित किया जाना चाहिए या नहीं, इस बारे में SO समुदाय विकि पर कुछ चर्चा हुई है। हालाँकि, मैंने डेटाबेस ऑब्जेक्ट के लिए बिल्ड-ऑटोमेशन प्रक्रिया बनाने के लिए सर्वोत्तम-प्रथाओं के बारे में बहुत चर्चा नहीं देखी है।

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

मैं एसओ समुदाय से कुछ विचार सुनना चाहूंगा कि वास्तविक दुनिया में कौन सी प्रथाएं प्रभावी हैं।

मुझे एहसास है कि यह कुछ व्यक्तिपरक है जो अभ्यास वास्तव में सबसे अच्छे हैं, लेकिन मुझे लगता है कि कई लोगों के लिए कौन सा काम उपयोगी हो सकता है, इसके बारे में एक अच्छा संवाद है।

इस विषय में चिंता के क्षेत्रों के बारे में मेरे कुछ टीज़र प्रश्न हैं। ये एक निश्चित सूची होने के लिए नहीं हैं - बल्कि लोगों के लिए एक शुरुआती बिंदु यह समझने में मदद करने के लिए कि मैं क्या देख रहा हूं।

1. क्या स्रोत नियंत्रण से परीक्षण और उत्पादन वातावरण दोनों का निर्माण किया जाना चाहिए?
   
   • क्या दोनों को स्वचालन का उपयोग करके बनाया जाना चाहिए - या स्थिर, अंतिम परीक्षण वातावरण से वस्तुओं की प्रतिलिपि बनाकर उत्पादन करना चाहिए?
   • आप तैनाती स्क्रिप्ट में परीक्षण और उत्पादन वातावरण के बीच संभावित अंतर से कैसे निपटते हैं?
   • आप कैसे परीक्षण करते हैं कि तैनाती स्क्रिप्ट उत्पादन के खिलाफ प्रभावी रूप से काम करेगी जैसा कि वे परीक्षण में करते हैं?
2. किस प्रकार की वस्तुओं को संस्करण नियंत्रित किया जाना चाहिए?
   • बस कोड (प्रक्रिया, पैकेज, ट्रिगर, जावा, आदि)?
   • इंडेक्स?
   • प्रतिबन्ध?
   • टेबल परिभाषाएँ?
   • तालिका परिवर्तन लिपियों? (उदाहरण के लिए। स्क्रिप्ट्स)
   • सब कुछ?
3. किस प्रकार की वस्तुओं को संस्करण नियंत्रित नहीं किया जाना चाहिए?
   • दृश्यों?
   • अनुदान?
   • उपयोगकर्ता का खाता?
4. आपके SCM रिपॉजिटरी में डेटाबेस ऑब्जेक्ट्स को कैसे व्यवस्थित किया जाना चाहिए?
   • आप रूपांतरण स्क्रिप्ट या ALTER स्क्रिप्ट जैसी एक बार की चीजों से कैसे निपटते हैं?
   • आप डेटाबेस से सेवानिवृत्त वस्तुओं से कैसे निपटते हैं?
   • विकास से लेकर परीक्षण स्तर तक वस्तुओं को बढ़ावा देने के लिए कौन जिम्मेदार होना चाहिए ?
   • आप कई डेवलपर्स से परिवर्तनों का समन्वय कैसे करते हैं?
   • आप कई सिस्टम द्वारा उपयोग किए जाने वाले डेटाबेस ऑब्जेक्ट के लिए ब्रांचिंग से कैसे निपटते हैं?
5. क्या अपवाद, यदि कोई हो, इस प्रक्रिया के लिए उचित हो सकता है?
   • सुरक्षा मुद्दे?
   • डी-आइडेंटिफिकेशन चिंताओं के साथ डेटा?
   • लिपियों को पूरी तरह से स्वचालित नहीं किया जा सकता है?
6. आप प्रक्रिया को लचीला और प्रवर्तनीय कैसे बना सकते हैं?
   • डेवलपर त्रुटि के लिए?
   • अप्रत्याशित पर्यावरण के मुद्दों के लिए?
   • आपदा वसूली के लिए?
7. आप निर्णय निर्माताओं को कैसे मनाते हैं कि डीबी-एससीएम के लाभ वास्तव में लागत को सही ठहराते हैं?
   • उपाख्यानात्मक सबूत?
   • उद्योग अनुसंधान?
   • उद्योग सबसे अच्छा अभ्यास सिफारिशें?
   • मान्यता प्राप्त अधिकारियों से अपील?
   • लागत लाभ विश्लेषण?
8. इस मॉडल में डेटाबेस ऑब्जेक्ट्स "स्वयं" कौन होना चाहिए?
   • डेवलपर्स?
   • DBAs?
   • डेटा विश्लेषक?
   • एक से अधिक?

Comments

इस सवाल की गहराई एक इनाम के लिए भीख माँगती है।

— ग्रेग डी

यह भी देखें stackoverflow.com/questions/115369/…

— टिम एबेल

Answer 1

यहां आपके सवालों के कुछ जवाब दिए गए हैं:

1. क्या स्रोत नियंत्रण से परीक्षण और उत्पादन वातावरण दोनों का निर्माण किया जाना चाहिए? हाँ
   • क्या दोनों को स्वचालन का उपयोग करके बनाया जाना चाहिए - या स्थिर, अंतिम परीक्षण वातावरण से वस्तुओं की प्रतिलिपि बनाकर उत्पादन करना चाहिए?
   • दोनों के लिए स्वचालन। पर्यावरण के बीच डेटा की नकल न करें
   • आप तैनाती स्क्रिप्ट में परीक्षण और उत्पादन वातावरण के बीच संभावित अंतर से कैसे निपटते हैं?
   • टेम्प्लेट का उपयोग करें, ताकि वास्तव में आप प्रत्येक वातावरण के लिए स्क्रिप्ट के विभिन्न सेट का उत्पादन करें (उदाहरण। बाहरी सिस्टम, लिंक किए गए डेटाबेस, आदि।)
   • आप कैसे परीक्षण करते हैं कि तैनाती स्क्रिप्ट उत्पादन के खिलाफ प्रभावी रूप से काम करेगी जैसा कि वे परीक्षण में करते हैं?
   • आप उन्हें पूर्व-उत्पादन वातावरण पर परीक्षण करते हैं: उत्पादन वातावरण की सटीक प्रतिलिपि पर परीक्षण परिनियोजन (डेटाबेस और संभवतः अन्य सिस्टम)
2. किस प्रकार की वस्तुओं को संस्करण नियंत्रित किया जाना चाहिए?
   • बस कोड (प्रक्रिया, पैकेज, ट्रिगर, जावा, आदि)?
   • इंडेक्स?
   • प्रतिबन्ध?
   • टेबल परिभाषाएँ?
   • तालिका परिवर्तन लिपियों? (उदाहरण के लिए। स्क्रिप्ट्स)
   • सब कुछ?
   • सब कुछ, और:
     • स्थिर डेटा (लुकअप सूची आदि) को मत भूलना, इसलिए आपको वातावरण के बीच किसी भी डेटा को कॉपी करने की आवश्यकता नहीं है
     • डेटाबेस स्क्रिप्ट का केवल वर्तमान संस्करण रखें (संस्करण नियंत्रित, निश्चित रूप से), और
     • स्टोर स्क्रिप्ट: 1 बिग स्क्रिप्ट (या 001_AlterXXX.sql पसंद की गई स्क्रिप्ट की निर्देशिका, ताकि उन्हें प्राकृतिक क्रम में चलाने से संस्करण A से B तक अपग्रेड हो जाए)
3. किस प्रकार की वस्तुओं को संस्करण नियंत्रित नहीं किया जाना चाहिए?
   • दृश्यों?
   • अनुदान?
   • उपयोगकर्ता का खाता?
   • देखें 2. यदि आपके उपयोगकर्ता / भूमिकाएँ (या तकनीकी उपयोगकर्ता नाम) वातावरण के बीच भिन्न हैं, तो आप अभी भी उन्हें टेम्प्लेट का उपयोग करके स्क्रिप्ट कर सकते हैं (देखें 1.)
4. आपके SCM रिपॉजिटरी में डेटाबेस ऑब्जेक्ट्स को कैसे व्यवस्थित किया जाना चाहिए?
   • आप रूपांतरण स्क्रिप्ट या ALTER स्क्रिप्ट जैसी एक बार की चीजों से कैसे निपटते हैं?
   • देखें २।
   • आप डेटाबेस से सेवानिवृत्त वस्तुओं से कैसे निपटते हैं?
   • DB से हटा दिया, स्रोत नियंत्रण ट्रंक / टिप से हटा दिया
   • विकास से लेकर परीक्षण स्तर तक वस्तुओं को बढ़ावा देने के लिए कौन जिम्मेदार होना चाहिए?
   • देव / परीक्षण / रिलीज अनुसूची
   • आप कई डेवलपर्स से परिवर्तनों का समन्वय कैसे करते हैं?
   • प्रत्येक डेवलपर के लिए एक अलग डेटाबेस बनाने का प्रयास न करें। आप स्रोत-नियंत्रण का उपयोग करें, है ना? इस मामले में डेवलपर्स डेटाबेस और चेक-इन लिपियों को बदलते हैं। पूरी तरह से सुरक्षित होने के लिए, रात के निर्माण के दौरान स्क्रिप्ट से डेटाबेस को फिर से बनाएं
   • आप कई सिस्टम द्वारा उपयोग किए जाने वाले डेटाबेस ऑब्जेक्ट के लिए ब्रांचिंग से कैसे निपटते हैं?
   • कठिन एक: हर कीमत पर बचने की कोशिश करें।
5. क्या अपवाद, यदि कोई हो, इस प्रक्रिया के लिए उचित हो सकता है?
   • सुरक्षा मुद्दे?
   • परीक्षण / ठेस के लिए पासवर्ड स्टोर न करें। आप इसे देवता के लिए अनुमति दे सकते हैं, खासकर यदि आपके पास दैनिक / रात्रिकालीन रूप से डीबी पुनर्निर्माण हो
   • डी-आइडेंटिफिकेशन चिंताओं के साथ डेटा?
   • लिपियों को पूरी तरह से स्वचालित नहीं किया जा सकता है?
   • दस्तावेज़ और रिलीज़ जानकारी / अलर्ट स्क्रिप्ट के साथ स्टोर करें
6. आप प्रक्रिया को लचीला और प्रवर्तनीय कैसे बना सकते हैं?
   • डेवलपर त्रुटि के लिए?
   • खरोंच से दैनिक निर्माण के साथ परीक्षण किया गया, और वृद्धिशील उन्नयन के परिणामों की तुलना करें (संस्करण ए से बी के लिए ALTER का उपयोग करके)। परिणामी स्कीमा और स्थिर डेटा दोनों की तुलना करें
   • अप्रत्याशित पर्यावरण के मुद्दों के लिए?
   • संस्करण नियंत्रण और बैकअप का उपयोग करें
   • PROD डेटाबेस स्कीमा की तुलना करें कि आप क्या सोचते हैं, विशेष रूप से तैनाती से पहले। सुपरडुपरकोल डीबीए ने एक बग तय किया है जो आपके टिकट प्रणाली में कभी नहीं था :)
   • आपदा वसूली के लिए?
7. आप निर्णय निर्माताओं को कैसे मनाते हैं कि डीबी-एससीएम के लाभ वास्तव में लागत को सही ठहराते हैं?
   • उपाख्यानात्मक सबूत?
   • उद्योग अनुसंधान?
   • उद्योग सबसे अच्छा अभ्यास सिफारिशें?
   • मान्यता प्राप्त अधिकारियों से अपील?
   • लागत लाभ विश्लेषण?
   • अगर डेवलपर्स और डीबीए सहमत हैं, तो आपको किसी को समझाने की ज़रूरत नहीं है, मुझे लगता है (जब तक कि आपको MSSQL के लिए एक dbGhost जैसे सॉफ़्टवेयर को खरीदने के लिए पैसे की आवश्यकता न हो )
8. इस मॉडल में डेटाबेस ऑब्जेक्ट्स "स्वयं" कौन होना चाहिए?
   • डेवलपर्स?
   • DBAs?
   • डेटा विश्लेषक?
   • एक से अधिक?
   • आमतौर पर डीबीए मॉडल को मंजूरी देते हैं (चेक-इन से पहले या कोड समीक्षा के हिस्से के रूप में)। वे निश्चित रूप से प्रदर्शन से संबंधित वस्तुओं के मालिक हैं। लेकिन सामान्य तौर पर टीम के मालिक होते हैं [और नियोक्ता, निश्चित रूप से :)]

Comments

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

— 20

स्पष्ट। मुझे लगता है कि आपने बहुत अच्छा सवाल उठाया है। और मैं वास्तव में आशा करता हूं कि विषय पर एक महान हॉव्टो विकी को संकलित करने के लिए प्रश्न को पर्याप्त कर्षण मिलेगा। ---- उपकरणों से: मैंने इनोवार्टिस से dbGhost का उपयोग किया, जिसका मैंने MSSQL सर्वर के प्रबंधन के लिए जवाब में उल्लेख किया और इसने बहुत अच्छा काम किया। संभवतः नौकरी के लिए अन्य उपकरण हैं, लेकिन यह देखते हुए कि पूर्ण एसक्यूएल स्कीमा विक्रेताओं के बीच वास्तव में मानक नहीं है, सभी ऑल-इन-वन समाधान (सभी SCM और RDMBS के लिए) नहीं है।

— वैन

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

— रिचर्ड लेवासेउर

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

— वैन

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

— कलंक

Answer 2

जब संभव हो तो मैं SQL को स्रोत-कोड के रूप में मानता हूं

अगर मैं इसे मानक के अनुरूप एसक्यूएल में लिख सकता हूं तो यह आम तौर पर मेरे स्रोत नियंत्रण में एक फ़ाइल में जाता है। फ़ाइल SPs, टेबल क्रेट स्टेटमेंट्स के रूप में ज्यादा से ज्यादा परिभाषित करेगा।

मैं स्रोत नियंत्रण में परीक्षण के लिए डमी डेटा भी शामिल करता हूं:

1. proj / एसक्यूएल / setup_db.sql
2. proj / एसक्यूएल / dummy_data.sql
3. proj / एसक्यूएल / mssql_specific.sql
4. proj / एसक्यूएल / mysql_specific.sql

और फिर मैं अपने सभी एसक्यूएल प्रश्नों को समाप्त कर देता हूं ताकि मैं MySQL, Oracle, MSSQL या कुछ और के लिए पूरी परियोजना का निर्माण कर सकूं।

बिल्ड और टेस्ट ऑटोमेशन इन बिल्ड-स्क्रिप्ट का उपयोग करता है क्योंकि वे ऐप स्रोत के रूप में महत्वपूर्ण हैं और ट्रिगर, प्रक्रियाओं और लॉगिंग के माध्यम से अखंडता से सब कुछ परीक्षण करते हैं।

Answer 3

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

प्रत्येक बिल्ड में SQL स्क्रिप्ट का अपना संग्रह होता है, जो $ प्रोजेक्ट \ SQL \ डायरेक्टरी में सोर्स कंट्रोल में स्टोर किया जाता है, एक संख्यात्मक उपसर्ग और क्रम में निष्पादित किया जाता है। इस तरह, हम हर निर्माण में अपनी तैनाती प्रक्रिया का अभ्यास कर रहे हैं।

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

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

Answer 4

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

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

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

Tha माइनस यह है कि LiquiBase doesnt व्यापक SQL IDE में एकीकृत है और आपको अपने आप को मूल संचालन करना चाहिए।

इसके अलावा आप DB परीक्षण के लिए DBUnit का उपयोग कर सकते हैं - यह उपकरण क्लीनअप aftewards के साथ अपने उत्पादन env के परीक्षण के लिए डेटा उत्पादन स्क्रिप्ट का उपयोग करने की अनुमति देता है।

IMHO:

1. डीएमएल को फाइलों में स्टोर करें ताकि आप उन्हें वर्जन दे सकें।
2. स्रोत नियंत्रण से स्वचालित स्कीमा निर्माण प्रक्रिया।
3. परीक्षण उद्देश्यों के लिए डेवलपर निर्माण नियंत्रण प्रणाली के माध्यम से स्रोत नियंत्रण से निर्मित स्थानीय डीबी का उपयोग कर सकता है। स्क्रिप्ट के साथ डेटा लोड करना, या डीबीयूनिट स्क्रिप्ट (स्रोत नियंत्रण से)।
4. LiquiBase आपको निर्भरता का सम्मान करने के लिए स्क्रिप्ट के "रन अनुक्रम" प्रदान करने की अनुमति देता है।
5. डीबीए टीम होनी चाहिए जो उत्पादन उपयोग से पहले सभी परिवर्तनों के साथ मास्टर ब्रंच की जांच करती है। मेरा मतलब है कि वे अन्य डीबीए से मास्टर ट्रंक में करने से पहले ट्रंक / शाखा की जांच करते हैं। ताकि मास्टर हमेशा सुसंगत और उत्पादन तैयार रहे।

हमने अपने बिलिंग उत्पादन डेटाबेस में कोड परिवर्तन, विलय, पुनर्लेखन के साथ सभी उल्लिखित समस्याओं का सामना किया। यह विषय उस सभी चीजों की खोज के लिए बहुत अच्छा है।

Answer 5

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

Comments

मुझे लगता है कि यह संभावना नहीं है कि उत्तर पर एक एकल, सार्वभौमिक रूप से सहमति हो सकती है। लेकिन मैं समझौते के कुछ सामान्य क्षेत्रों की पहचान करना चाहूंगा - और शायद एक उचित सिफारिश को इकट्ठा करूं। मैं निश्चित रूप से agileDat डेटाबेस फोरम पर और साथ ही धन्यवाद को देखूंगा।

— LBushkin

Answer 6

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

• डेटाबेस ऑब्जेक्ट्स को एक एकल SQL फ़ाइल लॉन्च करके स्क्रैच से हमेशा बनाया जा सकता है (जो स्वयं अन्य SQL फ़ाइलों को कॉल कर सकता है) Create.sql:। इसमें स्थैतिक डेटा सम्मिलन (सूची ...) शामिल हो सकते हैं ।
• एसक्यूएल स्क्रिप्ट्स को पैरामीटर किया जाता है ताकि कोई भी पर्यावरण-निर्भर और / या संवेदनशील जानकारी सादे फ़ाइलों में संग्रहीत न हो।
• मैं लांच करने के लिए कस्टम बैच फ़ाइल का उपयोग Create.sql: Create.cmd। इसका लक्ष्य मुख्य रूप से पूर्व-आवश्यकताएँ (उपकरण, पर्यावरण चर ...) की जांच करना और SQL स्क्रिप्ट में पैरामीटर भेजना है। यह प्रदर्शन के मुद्दों के लिए CSV फ़ाइलों से स्थिर डेटा को बल्क-लोड भी कर सकता है ।
• आमतौर पर, सिस्टम उपयोगकर्ता क्रेडेंशियल को Create.cmdफ़ाइल के लिए एक पैरामीटर के रूप में पारित किया जाएगा ।

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

एक बार डेटाबेस का पहला संस्करण उत्पादन में डाल दिया गया है, तो आपको न केवल स्क्रिप्ट (मुख्य रूप से डेवलपर्स के लिए) बनाने की आवश्यकता होगी, बल्कि स्क्रिप्ट को अपग्रेड भी करना होगा (समान सिद्धांतों पर आधारित):

• डेटाबेस से संस्करण को पुनः प्राप्त करने का एक तरीका होना चाहिए (मैं एक संग्रहीत प्रक्रिया का उपयोग करता हूं, लेकिन एक तालिका भी ऐसा करेगी)।
• एक नया संस्करण जारी करने से पहले, मैं एक Upgrade.sqlफाइल बनाता हूं (जो अन्य कॉल कर सकते हैं) जो संस्करण N-1 को संस्करण N में अपग्रेड करने की अनुमति देता है (एन संस्करण जारी किया जा रहा है)। मैं इस स्क्रिप्ट को नामित फ़ोल्डर के तहत संग्रहीत करता हूं N-1।
• मेरे पास एक बैच फ़ाइल है जो अपग्रेड करती है Upgrade.cmd:। यह डेटाबेस के वर्तमान संस्करण (CV) को एक सरल चयन कथन के माध्यम से पुनः प्राप्त कर सकता है , फ़ोल्डर के Upgrade.sqlनीचे संग्रहीत स्क्रिप्ट लॉन्च कर सकता है CV, और जब तक कोई फ़ोल्डर नहीं मिलता है तब तक लूप। इस तरह, आप स्वचालित रूप से कह सकते हैं, कहते हैं, एन -3 से एन।

इसके साथ समस्याएं हैं:

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

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

Answer 7

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

तैनाती के लिए यह संभव नहीं है क्योंकि डेटाबेस बहुत बड़े हैं: यह पहली जगह में डेटाबेस में होने का मुख्य कारण है।

Answer 8

मेरा दृढ़ता से मानना ​​है कि एक DB स्रोत नियंत्रण का हिस्सा होना चाहिए और निर्माण प्रक्रिया का एक बड़ा हिस्सा होना चाहिए। यदि यह स्रोत नियंत्रण में है तो मेरे पास SQL ​​में संग्रहीत कार्यविधि लिखते समय समान कोडिंग सुरक्षित गार्ड है जैसा कि मैं C # में कक्षा लिखते समय करता हूं। मैं अपने स्रोत पेड़ के नीचे एक DB स्क्रिप्ट निर्देशिका को शामिल करके ऐसा करता हूं। यह स्क्रिप्ट निर्देशिका जरूरी नहीं कि डेटाबेस में एक वस्तु के लिए एक फाइल हो। यह बट में दर्द होगा! मैं अपने db में विकसित करता हूँ बस एक मैं अपने कोड प्रोजेक्ट में होता हूँ। फिर जब मैं अपने डेटाबेस के अंतिम संस्करण और वर्तमान में जिस पर मैं काम कर रहा हूं, के बीच अंतर करने के लिए तैयार हूं। मैं इसके लिए SQL तुलना का उपयोग करता हूं और यह सभी परिवर्तनों की एक स्क्रिप्ट उत्पन्न करता है। इस स्क्रिप्ट को तब मेरे db_update निर्देशिका में एक विशिष्ट नामकरण परंपरा के साथ सहेजा जाता है 1234_TasksCompletedInThisIteration जहां संख्या स्क्रिप्ट के सेट में अगला नंबर है, और नाम बताता है कि इस चेक में क्या किया जा रहा है। मैं इस तरह से करता हूं क्योंकि मेरी निर्माण प्रक्रिया का एक हिस्सा मैं एक नए डेटाबेस के साथ शुरू करता हूं जो तब इस निर्देशिका में स्क्रिप्ट का उपयोग करके प्रोग्राम बनाया जाता है। मैंने एक कस्टम NAnt कार्य लिखा है जो प्रत्येक स्क्रिप्ट के माध्यम से नंगे db पर इसकी सामग्री को निष्पादित करता है। जाहिर है अगर मुझे db में जाने के लिए कुछ डेटा की आवश्यकता है तो मेरे पास डेटा डालने की स्क्रिप्ट भी है। इसके कई फायदे भी हैं। एक, मेरे सभी सामान संस्करणित हैं। दो, प्रत्येक बिल्ड एक ताजा बिल्ड है जिसका अर्थ है कि मेरे विकास की प्रक्रिया में अपना रास्ता बनाने वाला कोई भी डरपोक सामान नहीं होगा (जैसे कि गंदा डेटा जो सिस्टम में विषमता का कारण बनता है)। तीन, जब देव टीम में एक नया आदमी जोड़ा जाता है, तो उन्हें बस नवीनतम प्राप्त करने की आवश्यकता होती है और मक्खी पर उनके लिए उनका स्थानीय देव बनाया जाता है। चार, मैं परीक्षण मामलों को चला सकता हूं (मैंने इसे अपने डेटाबेस पर "यूनिट टेस्ट" नहीं कहा है!) क्योंकि डेटाबेस की स्थिति प्रत्येक बिल्ड के साथ रीसेट है (मतलब मैं परीक्षण डेटा जोड़ने के बारे में चिंता किए बिना अपने रिपॉजिटरी का परीक्षण कर सकता हूं। डाटाबेस)।

यह सभी के लिए नहीं है।

यह हर प्रोजेक्ट के लिए नहीं है। मैं आमतौर पर ग्रीन फील्ड परियोजनाओं पर काम करता हूं जो मुझे यह सुविधा देता है!

Comments

खुशी है कि आप अपने डेटाबेस विकास जीवनचक्र के हिस्से के रूप में SQL तुलना का उपयोग कर रहे हैं। हमें लगता है कि हमने नए बदलाव लाने वाले डेवलपर्स की आसानी में सुधार किया है। SQL स्रोत नियंत्रण की जाँच करें। यह एसक्यूएल के साथ कंधे से कंधा मिलाकर डेवलपर सहयोग को आसान बनाने के साथ-साथ आपको अपने स्कीमा ऑब्जेक्ट्स स्रोत को नियंत्रित रखने की अनुमति देता है (बशर्ते आप एसवीएन या टीएफएस का उपयोग कर रहे हों)। red-gate.com/products/sql_source_control/index.htm

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

Answer 9

श्वेत टॉवर तर्कों में आने के बजाय, यहाँ एक समाधान है जिसने वास्तविक दुनिया की समस्याओं पर मेरे लिए बहुत अच्छा काम किया है।

खरोंच से डेटाबेस का निर्माण sql स्क्रिप्ट के प्रबंधन के रूप में संक्षेपित किया जा सकता है।

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

यह तब सभी आवश्यक स्क्रिप्ट को एक साथ मिलाएगा और उन्हें चलाएगा। यह तब रिकॉर्ड करता है कि कौन सी स्क्रिप्ट चलायी गयी है।

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

एक अच्छा परिचय यहाँ देखें:

http://code.google.com/p/dbdeploy/wiki/GettingStarted

Answer 10

आप पा सकते हैं कि लिक्विबेस आपको जो कुछ भी दिख रहा है, उसे संभालता है।

Answer 11

प्रत्येक डेवलपर का अपना स्थानीय डेटाबेस होना चाहिए, और टीम को प्रकाशित करने के लिए स्रोत कोड नियंत्रण का उपयोग करना चाहिए। मेरा समाधान यहाँ है: http://dbsourcetools.codeplex.com/ मज़े करो, - नाथन