एक डेटाबेस को नया स्वरूप देने के लिए सर्वोत्तम अभ्यास


24

मैं एक आवेदन के लिए एक डेटाबेस डिजाइन करते समय कुछ सामान्य सर्वोत्तम प्रथाओं से अवगत हूं, लेकिन क्या नया स्वरूप देना है?

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

वर्तमान कार्यक्रम ओरेकल फॉर्म्स में है, जो गैर-सामान्यीकृत तालिकाओं के एक समूह में बिखरा हुआ है, कभी-कभी कई पास-डुप्लिकेट तालिकाओं के साथ एक-दूसरे के डेटा पर मामूली वेरिएंट रखते हैं। अड़चनें अक्सर खराब-कार्यान्वित संग्रहीत प्रक्रियाओं के रूप में होती हैं। यहां तक ​​कि प्रकार भी सही नहीं लग रहे हैं। मैंने खराब डेटा के सभी प्रकारों का सामना किया है जो कि ओरेकल को लगता है लेकिन SQL सर्वर के आयात / निर्यात विज़ार्ड में फिट (और ठीक है) दिया गया है। (उदाहरण के लिए, दो अंकों के पूर्णांक पूर्ण डेटाइम का गठन नहीं करते हैं!)

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

रीराइट का अंतिम परिणाम एक वेब-आधारित संस्करण होने जा रहा है, जो ASP.NET पर MS SQL सर्वर के साथ बैक एंड के लिए चल रहा है।

मेरे अन्य दो डेवलपर टीममेट मेरे से बहुत बड़े हैं, दोनों व्यवसाय / एमआईएस पृष्ठभूमि के साथ हैं जबकि मेरा सीएस है। वरिष्ठ सदस्य का अनुभव लगभग विशेष रूप से ओरेकल के रूप में रहा है और अन्य सदस्य ने विजुअल बेसिक में ज्यादातर व्यावसायिक अनुप्रयोगों में काम किया है। हालाँकि मेरा डेटाबेस बैकग्राउंड MySQL या SQLite में प्रोजेक्ट्स के लिए नए डेटाबेस डिजाइन करने तक सीमित रहा है, ज्यादातर मेरे अंडरग्रेजुएट क्लासेस के लिए, मैं अनुभव के साथ केवल एक ही प्रतीत होता हूं जो वास्तव में डेटाबेस को डिजाइन कर रहा है।

मैंने पहले ही C # में एक छोटा सा प्रोग्राम लिखा है जो सभी मौजूदा डेटा को एक तटस्थ प्रारूप में पढ़ता है, फिर से कास्ट करने और एक नए डेटाबेस में रखने के लिए तैयार है। मैं डेस्टिनेशन डेटाबेस के डिज़ाइन के बाद लोड-इन कोड लिखने की योजना बनाता हूं, ताकि डेटा को नई सामान्यीकृत तालिकाओं में ठीक से विभाजित किया जा सके, नई बाधाओं का पालन करने के लिए सही क्रम में जोड़ा जाए, आदि। उसी प्रोग्राम को बाद में फिर से चलाया जा सकता है। वास्तविक नव तैनात समाप्त रीडिज़ाइन के लिए उत्पादन डेटा को कॉपी करने के लिए। यह पता लगाने के लिए मुख्य बात के रूप में डेटाबेस के वास्तविक रीडिज़ाइन को छोड़ देता है।

तो मेरे सवाल का दिल: मौजूदा एप्लिकेशन के डेटाबेस स्तर से रीडिज़ाइन करने के लिए कुछ सर्वोत्तम अभ्यास क्या हैं?


5
नई तकनीक से परिचित होने वाली अधिकांश टीम के बिना, परियोजना मीठी सफलता नहीं होगी। वर्णित वर्तमान तकनीकी प्रोफ़ाइल इस कार्य के लिए उपयुक्त नहीं है।
NoChance

2
मैं इमाम करीम से सहमत हूं, आपको कुछ महत्वपूर्ण कौशल याद आ रहे हैं। ऐसा लगता है कि आपकी टीम को किसी ऐसे व्यक्ति की कमी हो सकती है जो ASP.NET/C#, SQL सर्वर / DB डिज़ाइन और ऑब्जेक्ट ओरिएंटेड डिज़ाइन को उस स्तर पर जानता हो जिस स्तर पर आपको इस महत्वाकांक्षी प्रोजेक्ट को खींचने की आवश्यकता है।
jfrankcarr

3
मैं टिप्पणियों से सहमत हूं, लेकिन फिर भी, आपकी समस्या को स्पष्ट रूप से उजागर करने के लिए कौशल के लिए एक बड़ा +1, आपके कौशल सेट की सीमाओं को स्वीकार करना और सर्वोत्तम प्रथाओं की तलाश करना है। यह एक शुरुआत है।
SRKX

जवाबों:


23

मुझे लगता है कि आप पहले से ही जानते हैं कि एक डेटाबेस को कैसे सामान्य किया जाए।

सॉफ्टवेयर को नए डेटाबेस में ले जाने के दौरान जोखिम को कम करने के लिए आपको किन रणनीतियों की आवश्यकता होती है।

मैं जो सुझाव दे रहा हूं, वह कम जोखिम वाले ट्रेड-ऑफ के रूप में अधिक काम करता है।

डेटाबेस को सामान्य करें, और मूल डेटाबेस से डेटा के साथ सामान्यीकृत डेटाबेस को पॉप्युलेट करने के लिए एक प्रक्रिया बनाएं। मूल डेटाबेस आवेषण, अद्यतन और हटाने के लिए डेटाबेस होगा। सामान्यीकृत डेटाबेस केवल रूपांतरण के दौरान क्वेरी डेटाबेस होगा ।

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

नए सामान्यीकृत डेटाबेस की ओर इशारा करते हुए, अपने नए ASP.NET सिस्टम के क्वेरी भाग का निर्माण करें।

आपके नए सिस्टम से क्वेरी परिणाम मूल सिस्टम से क्वेरी परिणामों के साथ तुलना करना चाहिए।

आप इस बिंदु पर रुक सकते थे। यह एक व्यावसायिक निर्णय है, न कि तकनीकी निर्णय।

अपने अवकाश पर, आप अपने नए ASP.NET सिस्टम में नया इन्सर्ट / अपडेट / डिलीट फंक्शनलिटी बनाते हैं। जब आप नई कार्यक्षमता बनाते हैं, तो आप उस मूल सिस्टम के कुछ हिस्सों को बंद कर देते हैं जो मेल खाते हैं। कुछ बिंदु पर, मूल प्रणाली का कुछ भी नहीं रहता है।

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

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

यह कहे बिना जाना चाहिए कि आपकी आबादी की प्रक्रिया पूरी तरह से सुसंगत हो।


एक बहुत पुरानी पोस्ट जो मुझे पता है, लेकिन आप जो उल्लेख करते हैं, उसे करने की संभावना के साथ हम कर रहे हैं, हालांकि हमें "नए आरबी" में तत्काल प्रतिबिंब की आवश्यकता है। हम नए सामान्यीकृत प्रारूप के प्रतिनिधित्व के रूप में निर्मित विचारों पर विचार कर रहे हैं। क्या आपको लगता है कि यह काम कर सकता है?
वायर्ड ००

2

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

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


वांछित कौशल होने के महत्व को पहचानने के लिए +1।
नोचंस

दुर्भाग्य से, हम ठेकेदार हैं। यहाँ सभी प्रोग्रामर हैं। हमारी टीम लीड्स भी हैं, लेकिन पिछले दिनों हमारे बॉस ग्राहक की अपनी प्रबंधन प्रणाली के विभिन्न स्तर हैं।
यूटोपिया लिमिटेड

2

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

चूंकि आप SQL सर्वर का उपयोग कर रहे हैं, आप SSIS के माध्यम से वास्तविक माइग्रेशन कर सकते हैं।

परीक्षण मामलों का एक अच्छा ठोस सेट बनाएं ताकि आप तुलना कर सकें कि पुरानी प्रणाली के परिणाम नई प्रणाली के साथ समान हैं।

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


1

मैं डेटाबेस स्कीमा के फिर से डिजाइन के साथ लगभग रोजाना कई विरासत अनुप्रयोगों के समर्थन और आगे के विकास के साथ सामना कर रहा हूं, जो एमएस एक्सेस फाइलों (.mdb) के रूप में पैदा हुए थे और फिर बड़े डेटाबेस तक बड़े हुए कई सैकड़ों टेबल के साथ अब एमएस SQL ​​पर स्थित है। सर्वर लेकिन अभी भी मूल डिजाइन के "शिशु की कमी" है। यहाँ कुछ अभ्यास हैं जो मुझे मेरे लिए उपयोगी लगे:

अपने डेटाबेस स्कीमा की सार्वजनिक रूप से उपलब्ध सतह को छोटा करने का प्रयास करें।

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

केवल ये (दृश्य, संग्रहीत कार्यविधियाँ और स्केलर फ़ंक्शंस) बाहरी अनुप्रयोगों (ORM या सीधे) के लिए दिखाई देते हैं और सभी CRUD ऑपरेशन के लिए उपयोग किए जाते हैं। यह स्कीमा तब पूरी तरह से जमे हुए है, जबकि आंतरिक रूप से आप अंतर्निहित तालिकाओं को बदल सकते हैं, अपनी प्रक्रियाओं में सुधार कर सकते हैं आदि - यह आपके आवेदन की संगतता को नहीं तोड़ देगा।

वास्तविक-विश्व मानदंड के लिए अनुकूलित करने का प्रयास करें, न कि पुस्तकों से।

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

प्रोफाइलिंग सत्र रिकॉर्ड करें और उनका विश्लेषण करें।

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


0

यहाँ मेरा जवाब है:

  1. सबसे पहले वर्तमान डेटाबेस सिस्टम को समझें जितना आप कर सकते हैं। आपको इन सिस्टम के सभी उपयोगों के साथ-साथ उपयोगकर्ताओं को भी जानना होगा। आपको सिस्टम के साथ-साथ उन सभी स्रोतों को जानना होगा जो सिस्टम उनके स्रोत सिस्टम के रूप में कार्य कर रहे हैं।

  2. आपको सिस्टम के सभी विभिन्न उपयोगों की पहचान करने की आवश्यकता है, चाहे वह परिचालन या रिपोर्टिंग या दोनों के लिए हो। डेटाबेस का उपयोग करने वाले अनुप्रयोगों और अपस्ट्रीम सिस्टम को पहचानें। ऐसा करने से, आप मौजूदा डेटाबेस के उन तत्वों को जान पाएंगे जो अप्रचलित हैं और जिनकी अब आवश्यकता नहीं है।

  3. इसके अलावा वर्तमान ईटीएल प्रक्रिया का विश्लेषण करें और समझें जो डेटा को डेटाबेस में लोड करते हैं और डेटाबेस से डेटा निकालते हैं।

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

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

  6. सौभाग्य!

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.