2012-02-18 12 views
14

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

कौन सा दृष्टिकोण सर्वोत्तम है? क्या इस विषय पर साहित्य है (यानी कोई वेब या पुस्तक)?

अग्रिम धन्यवाद!

+4

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

+0

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

उत्तर

17

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

कहा जा रहा है, मैं, एकल डाटाबेस दृष्टिकोण पर विचार कर रहे इन कारणों से:

  1. रखरखाव: जब पंजीकृत 'ग्राहक' के अनुसार एक डेटाबेस चल रहा है, आप बहुत आसानी से एक स्थिति है जहाँ तक पहुंच जाएगा आपके ऐप की स्कीमा में किए गए किसी भी बदलाव या अपग्रेड को प्रत्येक डेटाबेस इंस्टेंस पर लागू किया जाना चाहिए। यह हास्यास्पद, तेज़ हो जाएगा।

  2. सुविधा: आप विश्लेषण और उपयोग आंकड़े, या इन सभी डेटाबेस को प्रशासित करने के लिए कुछ तरीका चाहते हैं। एक डेटाबेस को क्वेरी करना आपके सभी डेटाबेस के लिए एक ही क्वेरी को एकत्र करने की कोशिश करने के लिए तुलनात्मक रूप से तुच्छ है। यह पैमाने पर नहीं जा रहा है।

  3. अनुमापकता *: के रूप में 2 में उल्लेख किया है, तो आप एक पूरे के रूप में अपने अनुप्रयोग अपने ग्राहकों के बारे में बातें क्वेरी करने के लिए एकत्रीकरण एक विशेष प्रकार की आवश्यकता के लिए जा रहे हैं, और। आपका ऐप जितना बड़ा हो जाएगा उतना ही जटिल होगा। दूसरा मुद्दा यह है कि, यदि कोई क्लाइंट ऐप का उपयोग दूसरे से बहुत अधिक करता है, तो आपको अनुकूलित करने के लिए क्या प्रोत्साहित किया जाएगा? आपका ऐप, बड़ा ग्राहक का डेटाबेस, या छोटा ग्राहक? जो कुछ भी आप बदलते हैं उसे भूलना सभी डेटाबेस में कॉपी करना है।

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

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

  6. सरलीकरण: आपके पास प्रति क्लाइंट डेटाबेस है और केवल एक ही उपयोग करना चाहते हैं। चीजों को तोड़ने के बिना आप उन्हें एक साथ कैसे मिलाते हैं? यदि आप ऑटो वृद्धिशील आईडी का उपयोग करते हैं तो प्राथमिक कुंजी विवाद होंगे; यदि आप कुंजी को पुन: उत्पन्न करने का निर्णय लेते हैं तो बुकमार्क किए गए यूआरएल तोड़ देंगे; टेबल पर विदेशी कुंजी अब सही रिकॉर्ड को इंगित नहीं करेंगे। आपकी डेटा अखंडता पैन नीचे जायेगी।

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

http://client.example.com 
http://example.com/client 

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

* @ xQbert कई डेटाबेस के साथ स्केलेबिलिटी के बहुत वास्तविक लाभ का उल्लेख करता है। मैंने यह जवाब स्पष्ट करने के लिए संशोधित किया है कि मैं अन्य पहलुओं से अधिक चिंतित था।

+1

बेहद गहन उत्तर के लिए धन्यवाद fuzzyDunlop। मैं इस तरह से जाने की ओर झुका रहा था, लेकिन खुद को अनुमान लगाने लगा। ऐसा लगता है कि मैं सही दिशा में जा रहा था – ralph

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