आप चाहेंगे कि आपने अलग डेटाबेस का उपयोग किया होता:
- यदि आप कभी भी डेटाबेस को स्वयं क्लाइंट या सुपरयूज़र को अनुमति देना चाहते हैं।
- यदि आप दूसरों के डेटा को प्रभावित किए बिना केवल एक क्लाइंट के डेटाबेस को पुनर्स्थापित करना चाहते हैं।
- यदि आपके डेटा और डेटा उल्लंघनों को नियंत्रित करने वाली नियामक चिंताएं हैं, और आपको देर से पता चलता है कि इन नियमों को केवल अलग डेटाबेस होने से ही पूरा किया जा सकता है। (अपडेट:इस उत्तर को लिखने के 4 साल बाद, GDPR प्रभावी हो गया)
- यदि आप कभी भी अपने ग्राहक डेटा को कई डेटाबेस सर्वरों में आसानी से स्थानांतरित करना चाहते हैं या अन्यथा स्केल आउट करना चाहते हैं, या बड़े/अधिक महत्वपूर्ण ग्राहकों को विभिन्न हार्डवेयर में स्थानांतरित करना चाहते हैं। दुनिया के एक अलग हिस्से में।
- यदि आप कभी भी पुराने ग्राहक डेटा को आसानी से संग्रहित और हटाना चाहते हैं।
- यदि आपके ग्राहक अपने डेटा को गुप्त रखने की परवाह करते हैं, और उन्हें पता चलता है कि आपने अन्यथा किया।
- यदि आपका डेटा समन किया गया है और केवल एक ग्राहक का डेटा निकालना कठिन है, या सम्मन अत्यधिक व्यापक है और आपको केवल एक क्लाइंट के लिए डेटा के बजाय संपूर्ण डेटाबेस तैयार करना होगा।
- जब आप सतर्कता बनाए रखना भूल जाते हैं और केवल एक क्वेरी निकल जाती है जिसमें
AND CustomerID = @CustomerIDशामिल नहीं होता है . संकेत:एक स्क्रिप्टेड अनुमति उपकरण, या स्कीमा का उपयोग करें, या सभी तालिकाओं को उन दृश्यों के साथ लपेटें जिनमेंWHERE CustomerID = SomeUserReturningFunction()शामिल हैं , या इनमें से कुछ संयोजन। - जब आपको एप्लिकेशन स्तर पर गलत अनुमतियां मिलती हैं और ग्राहक डेटा गलत ग्राहक के सामने आ जाता है।
- जब आप अलग-अलग क्लाइंट के लिए अलग-अलग स्तरों के बैकअप और पुनर्प्राप्ति सुरक्षा चाहते हैं।
- एक बार जब आप महसूस करते हैं कि नए डेटाबेस बनाने, प्रावधान करने, कॉन्फ़िगर करने, तैनात करने और अन्यथा स्पिन अप/डाउन करने के लिए एक बुनियादी ढांचे का निर्माण निवेश के लायक है क्योंकि यह आपको इसमें अच्छा होने के लिए मजबूर करता है।
- जब आपने किसी वर्ग के लोगों को एकाधिक ग्राहकों के डेटा तक पहुंच की आवश्यकता की संभावना की अनुमति नहीं दी, और आपको
Customerके शीर्ष पर अमूर्तता की एक परत की आवश्यकता है क्योंकिWHERE CustomerID = @CustomerIDअब इसे नहीं काटेंगे। - जब हैकर्स आपकी साइट या सिस्टम को लक्षित करते हैं, और आपने उनके लिए अपने सभी ग्राहकों का सारा डेटा एक ही बार में प्राप्त करना आसान बना दिया है, तो केवल एक में व्यवस्थापक क्रेडेंशियल प्राप्त करने के बाद झपट्टा मारा गया। डेटाबेस।
- जब आपके डेटाबेस बैकअप को चलने में 5 घंटे लगते हैं और फिर विफल हो जाता है।
- जब आपको अपने DBMS का एंटरप्राइज़ संस्करण प्राप्त करना हो ताकि आप संपीड़ित बैकअप बना सकें ताकि नेटवर्क पर बैकअप फ़ाइल की प्रतिलिपि बनाने में 5 घंटे से कम समय लगे अधिक ।
- जब आपको हर दिन पूरे डेटाबेस को एक परीक्षण सर्वर पर पुनर्स्थापित करना होता है जिसमें 5 घंटे लगते हैं, और सत्यापन स्क्रिप्ट चलाते हैं जिसे पूरा होने में 2 घंटे लगते हैं।
- जब आपके केवल कुछ ग्राहकों को प्रतिकृति की आवश्यकता होती है और आपको इसे केवल कुछ ग्राहकों के बजाय अपने सभी ग्राहकों पर लागू करना होता है।
- जब आप एक सरकारी ग्राहक को लेना चाहते हैं और यह पता लगाना चाहते हैं कि उन्हें आपको एक अलग सर्वर और डेटाबेस का उपयोग करने की आवश्यकता है, लेकिन आपका पारिस्थितिकी तंत्र एक ही सर्वर और डेटाबेस के आसपास बनाया गया था और यह बहुत कठिन है या इसे बदलने में बहुत समय लगेगा ।
आपको खुशी होगी कि आपने अलग डेटाबेस का उपयोग किया:
- जब एक ग्राहक के लिए एक पायलट रोलआउट पूरी तरह से विस्फोट हो जाता है और अन्य 999 ग्राहक पूरी तरह से अप्रभावित रहते हैं। और आप समस्या को ठीक करने के लिए बैकअप से पुनर्स्थापित कर सकते हैं।
- जब आपका कोई डेटाबेस बैकअप विफल हो जाता है और आप पूरी 10-घंटे की प्रक्रिया को फिर से शुरू करने के बजाय 25 मिनट में बस उसे ठीक कर सकते हैं।
आप चाहते हैं कि आपने एक ही डेटाबेस का उपयोग किया होता:
- जब आप एक बग खोजते हैं जो सभी 1000 क्लाइंट को प्रभावित करता है और 1000 डेटाबेस में सुधार को लागू करना कठिन होता है।
- जब आपको डेटाबेस स्तर पर गलत अनुमति मिलती है और ग्राहक डेटा गलत ग्राहक के सामने आ जाता है।
- जब आपने किसी वर्ग के लोगों को सभी डेटाबेस के सबसेट तक पहुंच की आवश्यकता की संभावना की अनुमति नहीं दी थी (शायद दो ग्राहक मर्ज करते हैं)।
- जब आपने नहीं सोचा था कि डेटा के दो अलग-अलग डेटाबेस को मर्ज करना कितना मुश्किल होगा।
- जब आपने डेटा के दो अलग-अलग डेटाबेस को मर्ज किया और महसूस किया कि एक गलत था, और आपने इस परिदृश्य से उबरने की योजना नहीं बनाई थी।
- जब आप एक सर्वर पर पिछले 32,767 ग्राहकों/डेटाबेस को विकसित करने का प्रयास करते हैं और पाते हैं कि यह SQL सर्वर 2012 में अधिकतम है।
- जब आपको पता चलता है कि 1,000+ डेटाबेस को प्रबंधित करना आपकी कल्पना से भी बड़ा दुःस्वप्न है।
- जब आपको पता चलता है कि आप केवल एक तालिका में कुछ डेटा जोड़कर एक नए ग्राहक को ऑनबोर्ड नहीं कर सकते हैं, और आपको एक नए डेटाबेस पर अनुमतियाँ बनाने, पॉप्युलेट करने और सेट करने के लिए डरावनी और जटिल स्क्रिप्ट का एक गुच्छा चलाना होगा।
- जब आपको हर दिन 1000 डेटाबेस बैकअप चलाने होते हैं, तो सुनिश्चित करें कि वे सभी सफल हों, उन्हें नेटवर्क पर कॉपी करें, उन सभी को एक परीक्षण डेटाबेस में पुनर्स्थापित करें, और हर एक पर सत्यापन स्क्रिप्ट चलाएं, किसी भी विफलता की रिपोर्ट इस तरह से करें कि देखे जाने की गारंटी होगी, और जो आसानी से और जल्दी से कार्रवाई योग्य हैं। और फिर इनमें से 150 विभिन्न स्थानों पर विफल हो जाते हैं और एक बार में एक को ठीक करना पड़ता है।
- जब आपको पता चलता है कि आपको 1000 डेटाबेस के लिए प्रतिकृति सेट अप करनी होगी।
सिर्फ इसलिए कि मैंने एक के लिए और कारण सूचीबद्ध किए हैं इसका मतलब यह नहीं है कि यह बेहतर है।
कुछ पाठकों को MSDN:Multi से वैल्यू मिल सकती है। -टेनेंट डेटा आर्किटेक्चर . या शायद सास टेनेंसी ऐप डिज़ाइन पैटर्न . या यहां तक कि बहु-किरायेदार का विकास करना क्लाउड के लिए एप्लिकेशन, तीसरा संस्करण
