एक डेटाबेस का उपयोग कर एकाधिक आवेदन?

Question

सोचें डिज़ाइन: मेरे पास कई एप्लिकेशन हैं जो समान उपयोगकर्ता डेटाबेस साझा करते हैं! अन्य तालिकाओं को भी साझा किया जाता है जैसे उपयोगकर्ता गतिविधि लॉग, खरीद आदि

1) वैसे भी मेरा सवाल यह है कि अगर मैं सभी एप्लिकेशन को बस सब कुछ के लिए 1 डेटाबेस का उपयोग करना चाहता था! क्या मुझे स्केलेबिलिटी के साथ कोई समस्या होगी? या कोई अन्य समस्या यह कर रही है? क्या 1 डेटाबेस होना बेहतर है? ? या सबसे बुरा?

2) या क्या मुझे बस प्रत्येक एप्लिकेशन का अपना डेटाबेस होना चाहिए, फिर अनुप्रयोगों के बीच सामान्य तालिकाओं को साझा करने के लिए वेब सेवा का उपयोग करें?

Answer 1

आपके द्वारा साझा संसाधन तक पहुंचने वाली अधिक प्रक्रियाएं, अधिक संभावना है कि आप स्केलिंग/प्रदर्शन और समय के मुद्दों में शामिल हों।

भले ही आपके एप्लिकेशन छोटे हों, मैं इसके खिलाफ अनुशंसा करता हूं।

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

कम से कम, आमतौर पर उपयोग की जाने वाली तालिकाओं के साथ बातचीत करने के लिए एक सेवा बनाएं और अपने एप्लिकेशन सेवा के माध्यम से अनुरोध करें।

मैं संसाधनों को एक सामान्य स्थान में विलय करने की आपकी इच्छा के साथ सहानुभूति व्यक्त करता हूं, लेकिन मुझे लगता है कि इस मामले में आप लाइन के नीचे और अधिक कठिनाइयों के लिए स्वयं को स्थापित कर देंगे। मुझे नहीं लगता कि यह इसके लायक है।

आपके संपादन के जवाब में ... मैं विकल्प (2) के साथ जाऊंगा।

Answer 2

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

ब्लॉगर (Google ऐप) एक अच्छा उदाहरण है। ग्राहकों में से कोई भी सिर्फ उनके लिए एक सुविधा मांगने के लिए तैयार नहीं है, इसलिए ब्लॉगर सबसे अधिक संभावना एक स्कीमा/एक डेटाबेस में डालता है।

Answer 3

भले ही आपके पास एक डेटाबेस था, फिर भी आप SCHEMAS के उपयोग से उपयोगकर्ता ऑब्जेक्ट्स को अलग कर सकते हैं, फिर भी आप उपयोगकर्ताओं को केवल अपनी स्कीमा तक पहुंच सकते हैं और किसी और की स्कीमा नहीं। स्कीमा के बारे में यहां पढ़ें: http://msdn.microsoft.com/en-us/library/ms190387.aspx

Answer 4

अलग डेटाबेस न बनाएं। तब आपको बनाए रखने के लिए एक दुःस्वप्न होगा और चीजें सिंक से बाहर हो जाएंगी। अलग-अलग प्रणालियों में लोगों के अलग-अलग नाम और आईडी होंगे और यह अब तक का सबसे बुरा दुःस्वप्न होगा। एक सिस्टम में डुप्लिकेट अन्य लोगों में रिपोर्टिंग मुद्दों को बनाने वाले व्यक्ति से मेल खाते हैं। मिलान करने के लिए अलग-अलग सिस्टम प्राप्त करने का प्रयास करते समय बस रिपोर्ट लिखना बुरा होगा। इसके बजाय स्केलेबिलिटी के लिए योजना। डेटा विभाजन कैसे करें सीखें।

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

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

Answer 5

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

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

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

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

Answer 6

"या फिर मैं तो बस हर आवेदन के लिए अपने स्वयं डेटाबेस, है देना चाहिए"

1950 में, हर आवेदन फाइलों की अपनी निजी सेट था। एक दशक या उसके बाद, कुछ स्मार्ट लोगों ने यह देखना शुरू कर दिया कि उन "एप्लायंस-प्राइवेट फाइलों" के भीतर कुछ डेटा तत्व वास्तव में डुप्लिकेट जानकारी थीं। ग्राहक के नाम हर जगह थे, पॉइंट-ऑफ-बिक्री की जानकारी, हर जगह दोहराया गया था आदि आदि

डाटाबेस प्रौद्योगिकी अभी तक चालाक लोगों द्वारा आविष्कार किया गया था कि समस्या को हल करने के लिए।

और अब इन दिनों, डेटाबेस बनाने "एप्लिकेशन-निजी", इंटरनेट प्रोग्रामर की पीढ़ी बहुत ही समस्याओं कि पहले से ही 1960 में हल किया गया पुनर्जीवित कर रहे हैं द्वारा।

बस मेरा विचार, कुछ भी वास्तव में महत्वपूर्ण नहीं है।

"जो लोग इतिहास भूल जाते हैं, उन्हें दोहराने के लिए बर्बाद कर दिया जाता है"।