डुप्लिकेट टेबल बनाने से बचने के लिए समानार्थी शब्द का उपयोग करना एक अच्छा विचार है?

13

हमारे पास ठीक उसी डेटाबेस की 3 प्रतियां हैं। सभी 3 डेटाबेस में एक Usersतालिका है, और एक उपयोगकर्ता हमेशा एक ही सेटिंग के साथ सभी 3 डेटाबेस में मौजूद होगा। जब भी हम एक उपयोगकर्ता को जोड़ना या संपादित करना चाहते हैं, तो हमें 3 डेटाबेस अपडेट करने होंगे।

क्या Usersडेटाबेस 2 और 3 से तालिका को हटाना बेहतर होगा और इसे Synonymडेटाबेस 1 के बिंदुओं से प्रतिस्थापित किया जाएगा ?

यहाँ पेशेवरों / विपक्ष मैं के बारे में सोच सकते हैं:

पेशेवरों

आसान रखरखाव। उपयोगकर्ताओं को 3 के बजाय एक स्थान पर अपडेट कर सकते हैं
उपयोगकर्ता Ids डेटाबेस के बीच मेल खाते हैं (महत्वपूर्ण यह है कि बहुत सारे ऐड-ऑन ऐप्स UserId पर आधारित हैं)

विपक्ष

ऐसा मत सोचो कि यह मानक प्रक्रिया है, इसलिए भ्रमित हो सकती है
उपयोगकर्ताओं को डेटाबेस के बीच समान सेटिंग्स रखना होगा
( नीचे gbn के उत्तर से) यदि डेटाबेस 1 कभी नीचे जाता है, तो डेटाबेस 2 और 3 भी अनुपलब्ध होगा। पुनर्स्थापना की स्थिति में डेटा के असंगत होने की भी संभावित समस्या है

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

sql-server database-design

— राहेल
स्रोत

3

क्या उनके बीच के अंतरों को सिंक्रनाइज़ करने / मर्ज करने के लिए एक स्क्रिप्ट होना अधिक समझ में आएगा? मैं व्यक्तिगत रूप से इस तरह एक पर्यायवाची के कारण 2 डेटाबेस को एक तिहाई पर निर्भर करना पसंद नहीं करता।

— फ्रस्ट्रेटेडविथफॉर्म्सडिजेनर

@FrustratedWithFormsDesigner जो अधिक काम की तरह लगता है, और ऑटो-जनरेटेड फ़ील्ड जैसे प्राथमिक कुंजी में परिवर्तन को मर्ज करना कठिन है।

— राहेल

यह इस बात पर निर्भर करता है कि आप कैसा फैंसला पाना चाहते हैं। यदि आप उनके बीच परिवर्तन साझा करना चाहते हैं, तो हाँ यह जटिल हो सकता है। यदि आप किसी को मास्टर के रूप में नामित करना चाहते हैं, तो यह केवल मास्टर की सामग्री के साथ दूसरों की सामग्री को ओवरराइट करने का मामला है।

— FrustratedWithFormsDesigner

@FrustratedWithFormsDesigner दुर्भाग्य से एप्लिकेशन स्रोत बंद है और किसी भी डेटाबेस में उपयोगकर्ताओं को जोड़ने या संपादित करने से रोकने के लिए कुछ भी नहीं है। मुझे परिवर्तनों को दो-तरफा करना होगा क्योंकि सभी के पास अपना पासवर्ड बदलने की क्षमता है, और लगभग सभी प्रबंधकों को उपयोगकर्ताओं को जोड़ने / संपादित करने के लिए उपयोगकर्ता प्रबंधन तक पहुंच है।

— राहेल

6

आपके पास समान उपयोगकर्ताओं के साथ 3 डेटाबेस क्यों हैं?

यदि एक डेटाबेस अब नीचे जाता है तो क्या होगा?

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

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

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

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

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

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

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

समानार्थी शब्द का उपयोग करने के लिए एक अतिरिक्त कॉन यह है कि अब आप प्रत्येक डेटाबेस में उपयोगकर्ताओं को उचित FKs नहीं दे पाएंगे।

— ErikE
स्रोत

3

एक लापता "कोन" है

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

यही है, समानार्थी शब्द का उपयोग क्रॉस-डेटाबेस संदर्भात्मक अखंडता को ग्रहण करेगा जो वास्तविक जीवन में नहीं हो सकता है।

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

तो, यह मत करो ...

Dba.se पर संबंधित उत्तर: नॉन-डोब स्कीमा बनाम नए डेटाबेस का उपयोग करने के बारे में निर्णय मानदंड "क्रॉस-डेटाबेस रेफ़रेंशियल अखंडता" के बारे में पुनर्स्थापना के बाद

— GBN
स्रोत

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

— राहेल

1

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

— gbn

2

आपके डेटाबेस प्लेटफ़ॉर्म के आधार पर, डेटाबेस 2 और 3 में तालिकाओं को हटाने का एक और विकल्प डेटाबेस 1 में तालिका के भौतिक विचारों के साथ प्रतिस्थापित करना है ।

पेशेवरों

आसान रखरखाव (डेटा का)
मैचिंग आई.डी.एस.
आउटेज अन्य डेटाबेस को प्रभावित नहीं करते हैं (कम से कम जब तक परिवर्तन किए जाने की आवश्यकता है)
किसी भी डेटाबेस का उपयोग तालिका को पुनर्प्राप्त करने के लिए किया जा सकता है।

विपक्ष

डेटा केवल आपके ताज़ा कार्यक्रम के रूप में अद्यतित है।
यदि तालिका परिभाषा में परिवर्तन होता है तो भौतिक विचारों को भी बदलाव की आवश्यकता हो सकती है।

यह भी ध्यान दें कि लुक-अप की आवृत्ति, रिफ्रेश की आवृत्ति और डेटा परिवर्तन की आवृत्ति के आधार पर, यह एक पर्याय समाधान की तुलना में अधिक भार का परिचय दे सकता है या नहीं भी हो सकता है।

अद्यतन: FrustratedWithFormsDesigner की टिप्पणी अनिवार्य रूप से उन प्लेटफार्मों के लिए एक भौतिकीकृत दृश्य है जो भौतिक विचारों को नहीं कर सकते हैं। एक स्क्रिप्ट का उपयोग कर तालिकाओं को समय-समय पर सिंक्रनाइज़ किया जा सकता है। यदि एक डेटाबेस को मास्टर के रूप में नामित किया गया है तो सभी स्क्रिप्ट इसके आधार पर अपने बदलाव कर सकते हैं। यह सब एक भौतिक दृष्टिकोण के पेशेवरों और विपक्ष होगा; यह सिर्फ अंतर्निहित कार्यक्षमता का लाभ नहीं उठा सकता है।

— लेह रिफ़ल
स्रोत

1

आप SQL Server + में क्रॉस-डीबी (यहां अनुक्रमित विचार) नहीं देख सकते हैं, उन्हें ताज़ा करने की आवश्यकता नहीं है: वे "वास्तविक समय" हैं

— gbn

SQL सर्वर टैग जोड़े जाने से पहले मेरी पोस्ट मेरी पोस्ट लिखी गई थी।

— लेह रिफ़ेल

मैंने आपके उत्तर के आधार पर टैग जोड़ा है :)

— राहेल

1

मैं एक 4th DB बनाऊंगा जो साझा किए गए उपयोगकर्ता जानकारी को संग्रहीत करता है। उपयोगकर्ता डीबी की ओर इशारा करते हुए अन्य डीबीएस में से प्रत्येक में बनाएं Synonymsया बनाएं Views।

अंत में मैं एक एक्सटेंशन टेबल (प्रत्येक उपयोगकर्ता के लिए विशिष्ट डेटा रखने वाले 3 मौजूदा dbs में 'UserDB.Usertable' के साथ वन-वन रिलेशनशिप वाली तालिका) बनाऊंगा।

संपादित करें: नीचे टिप्पणी के आधार पर

उस स्थिति में मास्टर उपयोगकर्ता तालिका के रूप में फर्स्ट डीबी कार्य करें। Synonymsऔर अन्य Dbs में से प्रत्येक में एक विस्तार तालिका।

महत्वपूर्ण नोट : इस दृष्टिकोण के साथ, यदि आपका पहला ऐप डाउन हो जाता है, तो अन्य दो इसके साथ नीचे खींच लिए जाते हैं! सुनिश्चित करें कि हर कोई इस खामी को समझे।

— बेवकूफों
स्रोत

अफसोस की बात है कि मेरे लिए कोई विकल्प नहीं है। यह मेरा पसंदीदा विकल्प होगा अगर मैं खरोंच से कुछ डिजाइन कर रहा था, लेकिन इस मामले में मैं पहले से मौजूद सिस्टम के साथ काम कर रहा हूं। मेरे मामले में, हमारे पास डेटाबेस 1 था जो कई वर्षों से अस्तित्व में था, और हाल ही में डेटाबेस 2 और 3 को जोड़ा है

— राहेल

तालिकाओं को हटाकर पहले db को पर्यायवाची क्यों कहा जा सकता है लेकिन किसी नए को नहीं?

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

— राहेल

मैं आपका संपादन देख रहा हूं ... ठीक यही मैं करने की कोशिश कर रहा हूं, लेकिन मेरा सवाल यह था कि यह एक अच्छा विचार है या नहीं, और यदि नहीं, तो क्यों?

— राहेल

यह ठीक है। यदि आप ठीक हैं 2 समाचार एप्लिकेशन को पूरी तरह से पहले ऐप पर निर्भर करते हैं।