2008-09-19 8 views
14

एक विरासत डेटाबेस स्कीमा से फंसे हुए जो अब आपके डेटा मॉडल को प्रतिबिंबित नहीं करता है हर डेवलपर का दुःस्वप्न है। फिर भी रखरखाव के लिए कोड को रिफैक्टरिंग की सभी बातों के साथ मैंने पुरानी डेटाबेस स्कीमा को पुन: सक्रिय करने के बारे में बहुत कुछ नहीं सुना है।पुरानी डेटाबेस स्कीमा को रीफैक्टर करने पर युक्तियाँ

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


मेरे उदाहरण:

मेरी कंपनी प्राप्त करता है और जहाजों उत्पादों। अब एक उत्पाद रसीद और उत्पाद शिपमेंट में उनके साथ जुड़े कुछ बहुत ही अलग डेटा हैं, इसलिए मूल डेटाबेस डिजाइनरों ने रसीदों और शिपमेंट के लिए एक अलग तालिका बनाई है।

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

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

उत्तर

5

यहाँ डेटाबेस refactorings की एक पूरी सूची है:

http://databaserefactoring.com/

+0

उदाहरण के लिए, MySQL के लिए कुछ विशिष्ट है। मैं देखता हूं कि चार्ट हैं ... उदाहरण के लिए, एक लुकअप टेबल को खत्म करने के लिए कोई वास्तविक निर्देश नहीं है। –

+0

यह ज्यादातर आरडीबीएमएस-अज्ञेयवादी है। पुस्तक में स्वयं ही वास्तविक निर्देश हैं। * एक लुकअप टेबल * जोड़ने के लिए एक रिफैक्टरिंग है, इसे हटाने के लिए कोई नहीं देख सकता :) http://databaserefactoring.com/AddLookupTable.html –

0

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

उम्मीद है कि उनमें से कोई भी "चयन *" प्रश्न नहीं है। यदि वे करते हैं, तो कॉलम की पूरी सूची प्राप्त करने के लिए 'sp_help tablename' का उपयोग करें, इसे कॉपी करें और पूर्ण कॉलम सूची के साथ प्रत्येक * को प्रतिस्थापित करें, यह सुनिश्चित करने के लिए कि आप क्लाइंट कोड नहीं तोड़ते हैं।

मैं धीरे-धीरे परिवर्तन करने की सिफारिश करता हूं, और बहुत से एकीकरण परीक्षण करता हूं। कुछ बग पेश किए बिना एक महत्वपूर्ण रीमोडल करना मुश्किल है।

+0

कोई अनादर नहीं है, लेकिन यह 'सावधानीपूर्वक कार्य करने' से कम कोई वास्तविक सलाह नहीं देता है। मेरे मामले में 99% एक्सेस वास्तव में एसपी के साथ है लेकिन पीएल/एसक्यूएल कोड की हजारों लाइनें हैं, क्या आप डेटा माइग्रेशन पर कुछ पढ़ने की सिफारिश कर सकते हैं? –

+0

मुझे लगता है कि मुझे रिफैक्टरिंग के बारे में पढ़ने का बिंदु नहीं दिख रहा है, प्रति से। मुझे लगता है कि सही रणनीति सही स्कीमा को डिजाइन करना है (इसलिए डेटाबेस डिज़ाइन पर पढ़ना बेहतर होगा), और फिर एक बार ऐसा करने के बाद, डेटा को माइग्रेट करने और प्रोसेस को दोबारा लिखने का तरीका जानें। यह सब मामला मामला है। –

0

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

2

के आसपास काम करने के लिए एक बहुत ही मुश्किल बात है कि; डेटाबेस को पुन: सक्रिय करने के बाद कुछ त्वरित विकल्प हैं:

  • मूल स्कीमा से मेल खाने वाले दृश्य बनाएं लेकिन नई स्कीमा से खींचें; आपको यहां ट्रिगर्स की आवश्यकता हो सकती है ताकि विचारों के किसी भी अपडेट को संभाला जा सके।
  • नई स्कीमा बनाएं और दूसरी तरफ बनाए रखने के लिए प्रत्येक तरफ ट्रिगर्स डालें।
  • 1

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

    आपकी रसीदें और शिपमेंट तब विचार बन जाते हैं।

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

    +0

    सलाह के लिए धन्यवाद, वास्तव में वे बहुत ही अलग जानवर हैं, लेकिन चूंकि हम सिस्टम के साथ किए गए अधिकांश कार्यों में इन्वेंट्री से संबंधित हैं, इसलिए उन्हें –

    3

    This book (Refactoring Databases) किया गया है एक मेरे लिए ईश्वर भेज जब सहित जब मैं हमारे सूची डेटाबेस के लिए लगभग ठीक उसी मुद्दे से निपटने के लिए किया था विरासत डेटाबेस स्कीमा, के साथ काम कर।

    इसके अलावा, डेटाबेस स्कीमा में परिवर्तनों को ट्रैक करने के लिए एक सिस्टम होने के साथ (जैसे कि वह स्रोत नियंत्रण भंडार में संग्रहीत परिवर्तनों की एक श्रृंखला की तरह) कोड-टू-डेटाबेस निर्भरताओं को समझने में अत्यधिक मदद करता है।

    0

    मुझे यह नहीं लगता कि लेनदेन तालिका की आईडी रसीदइन्फो या शिपमेंटइन्फो के लिए एक विदेशी कुंजी होनी चाहिए। चारों ओर दूसरी तरफ सोचो। ऑब्जेक्ट उन्मुख मॉडल में आपके पास एक लेनदेन तालिका होनी चाहिए और रसीदइन्फो या शिपमेंटइन्फो के पास लेनदेन तालिका में एक विदेशी कुंजी होनी चाहिए। यदि आप भाग्यशाली हैं, तो कोड में केवल 1 या 2 अंक होंगे जहां रसीदइन्फो या शिपमेंटइन्फो में नए रिकॉर्ड बनाए जाएंगे। वहां आपको कोड जोड़ना चाहिए जहां आप लेनदेन तालिका में एक प्रविष्टि जोड़ते हैं और इसके बाद ट्रांजैक्शन के लिए विदेशी कुंजी के साथ रसीदइन्फो या शिपमेंटइन्फो में प्रविष्टि बनाते हैं।

    +0

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

    0

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

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

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