क्या मुझे प्रति एप्लिकेशन एक डेटाबेस का उपयोग करना चाहिए या एक ही डेटाबेस को कई अनुप्रयोगों के बीच साझा करना चाहिए [बंद]

33

मेरे पास कई एप्लिकेशन हैं जो समान स्रोतों से डेटा का उपयोग करते हैं। क्या यह सबसे अच्छा अभ्यास है (या पेशेवरों / विपक्ष क्या हैं):

एकाधिक अनुप्रयोगों द्वारा साझा किए गए डेटाबेस में डेटा को छोड़ दें
1. केवल एक डेटाबेस की आवश्यकता के रूप में स्थान बचाता है
2. अनुक्रमण को जटिल बनाता है क्योंकि विभिन्न अनुप्रयोगों में अलग-अलग क्वेरी की आवश्यकता होती है
प्रति-एप्लिकेशन डेटाबेस में प्रतिदिन डेटा आयात करें
1. प्रति एप्लिकेशन डेटाबेस में डुप्लिकेट किए गए डेटा के रूप में अधिक स्थान का उपयोग करता है
2. प्रत्येक एप्लिकेशन के रूप में आसान अनुक्रमण अपनी व्यक्तिगत जरूरतों पर ध्यान केंद्रित कर सकता है

मैंने अन्य फायदे / नुकसान छोड़ दिए हैं, कृपया सूची दें यदि कोई हो, तो यह आपके कार्यस्थल पर कैसे किया जाता है?

database database-design multitenancy

— Laz
स्रोत

1

आप एप्लिकेशन को कैसे परिभाषित कर रहे हैं: अलग-अलग बिल्ड, अलग-अलग डेवलपर्स?

— जेफ़ो

डेटाबेस को साझा करना पूरे डेटाबेस को एक बड़े और गड़बड़ सार्वजनिक एपीआई में बदल देता है। और यह उन सभी सार को याद कर रहा है जो आपने पहले एप्लिकेशन में बनाए होंगे।

— पैट्रिक

क्या प्रदर्शन एक मुद्दा है? पर्याप्त रिकॉर्ड के साथ, जो एक बड़े एकल डेटाबेस से एक को अलग कर देगा। स्पेस सस्ता है।

— रिग

41

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

कई अनुप्रयोगों के लिए एक डेटाबेस साझा करने से कुछ गंभीर नुकसान होते हैं :

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

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

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

— बाज़
स्रोत

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

— लज़

2

@ लाज़: संभवतः, उपयोग-मामलों और आवश्यकताओं पर निर्भर करता है।

— फाल्कन

2

संबंधपरक डेटाबेस डिज़ाइन के मूल सिद्धांतों में से एक में डुप्लिकेट डेटा नहीं है। एक ही डेटा के ओवरलैप वाले विभिन्न डेटाबेस होने से सिर्फ परेशानी हो रही है।

— पीटर बी

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

— फाल्कन

@PieterB: एक ही डेटा को पढ़ने और लिखने वाले कई एप्लिकेशन एक अच्छा संकेत है कि आपको एक सर्विस लेयर बनाना चाहिए जिसके खिलाफ सभी एप्लिकेशन रिक्वेस्ट कर सकें। दूसरी ओर, यदि वे अलग-अलग हैं जो आप एक सामान्य सेवा को प्रभावित नहीं कर सकते हैं, तो वे अलग-अलग टेबल / डेटाबेस की आवश्यकता के लिए पर्याप्त हैं।

— दान ल्योन

23

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

उदाहरण के लिए, कर्मचारी जानकारी के साथ काम करने के लिए आवश्यक सभी 3 एप्लिकेशन। माल और माल सूची की समान जानकारी का उपयोग दोनों सूची और खरीद प्रणाली कर रहे थे।

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

मैंने उपयोगकर्ताओं और सामानों के साथ बातचीत करने के लिए एक आम यूआई भी बनाया है जो अपने आप में एक अलग वेब एप्लिकेशन था।

इसलिए, @ फाल्कन ने जो इशारा किया है, मुझे लगता है कि आप एक डेटाबेस में अनुप्रयोगों के बीच सामान्य कार्यक्षमता को केंद्रीकृत करने से लाभ उठा सकते हैं।

— सईद नेमाटी
स्रोत

3

तार्किक पृथक्करण और स्वच्छ वास्तुकला का सुझाव देने के लिए +1। SOA इस तरह की चीजों को वास्तव में आसान बनाता है

— फाल्कन

तार्किक संगठन के लिए निश्चित रूप से +1। डेटा को युग्मन और सामंजस्य के संतुलन को अनुकूलित करने के लिए समूहीकृत किया जाए और फिर अनुप्रयोगों को उन डेटाबेसों में डुबोया जा सके जो उन्हें अपना काम करने की आवश्यकता है।

— जोएल ब्राउन

9

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

यदि प्रदर्शन एक समस्या बनने लगती है, तो चीजों को संतुलित करने के लिए db को कई सर्वरों पर दोहराया जाता है।

— GrandmasterB
स्रोत

3

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

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

— जारेड एस
स्रोत

+1: एक डेटाबेस में कई एप्लिकेशन को मैप करना काफी आसान है।

— केविन क्लाइन

0

एक बार मेरे पास कई वेबसाइटें थीं जो समय के साथ लोकप्रिय हो गईं। उन्होंने अलग-अलग डेटाबेस का उपयोग किया, ज्यादातर क्योंकि होस्टिंग प्रदाता ने केवल 1 जीबी स्टोरेज स्पेस की अनुमति दी। परंतु! जैसे ही मैंने एक सेवा जारी की जिसमें इन सभी वेबसाइटों को शामिल किया गया था, मुझे इन वेबसाइटों के बीच लेनदेन करना शुरू हो गया, और ऐसा करने का सबसे सुविधाजनक तरीका निश्चित रूप से एक बड़े डेटाबेस में सब कुछ बढ़ रहा है।

इसलिए मैंने डेटाबेस संरचना को अनुकूलित किया और इस केंद्रीय डेटाबेस के लिए प्रासंगिक भागों को निचोड़ दिया, लेकिन बाकी सब कुछ छोड़ दिया।

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

उपर्युक्त मामले में सामान्य डीबी का उपयोग करने से बचा नहीं जा सकता है, लेकिन याद रखें कि मैंने कुछ सारणियों को अलग डीबी में अलग रखा है, जो सामान्य प्रश्नों का हिस्सा नहीं हैं।

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

सभी सभी में, आप सामान्य प्रश्नों के लिए एक सामान्य डेटाबेस बनाए रख सकते हैं, लेकिन अपने प्रत्येक एप्लिकेशन के लिए एक भी रख सकते हैं।

— रापली आन्द्रे
स्रोत

0

क्या आप अपने एप्लिकेशन आर्किटेक्चर के बारे में अधिक विस्तार से बता सकते हैं?

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

— क्रिस मायलोनास
स्रोत