database - यवस - हिंदी में डेटाबेस डिजाइन की प्रक्रिया




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

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

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

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

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

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

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

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

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

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


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


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

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

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


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

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

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

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

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

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

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


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

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

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

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


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

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

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

Tha minus यह है कि LiquiBase व्यापक SQL IDE में एकीकृत नहीं है और आपको स्वयं को बुनियादी परिचालन करना चाहिए।

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

IMHO:

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

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


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

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

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

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

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

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





version-control