2010-12-15 9 views
13

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

इस ऐप में, ऐसा नहीं है डेटा के एक बाइट जिसे खातों के बीच साझा किया जाना है। ,

ALTER TABLE CardHolder ADD CONSTRAINT UQ_CardHolderName UNIQUE (CardHolderUniqueName); 
ALTER TABLE SmartCard ADD CONSTRAINT UQ_CardName UNIQUE (CardUniqueName); 

अब,

CREATE TABLE CardHolder ( 
    CardHolderID int, -- primary key 
    CardHolderUniqueName nvarchar(30)); 

CREATE TABLE SmartCard (
    SmartCardID int, -- primary key 
    CardHolderID int, 
    CardUniqueName nvarchar(30)); 

कि कुछ विशिष्टता की कमी में जोड़े अगर मैं एक डेटाबेस में सब कुछ डाल दिया:

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

CREATE TABLE CardHolder ( 
    CardHolderID int, -- primary key 
    CardHolderUniqueName nvarchar(30), 
    AccountID int); 

CREATE TABLE SmartCard (
    SmartCardID int, -- primary key 
    CardHolderID int, 
    CardUniqueName nvarchar(30) 
    AccountID int); 

ALTER TABLE CardHolder 
    ADD CONSTRAINT UQ_CardHolderName UNIQUE (AccountID, CardHolderUniqueName); 
ALTER TABLE SmartCard 
    ADD CONSTRAINT UQ_CardName UNIQUE (AccountID, CardUniqueName); 

वास्तविक DB में शामिल करना चाहिए, वहाँ (expirydate आदि आदि द्वारा लिस्टिंग के लिए) से अधिक टेबल, स्तंभों और कई अनुक्रमित का भार हो जाएगा और खाते के स्तंभ हर जगह शामिल किया जाना है ।

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

उत्तर

6

आपके प्रश्न राज्य, स्कीमा डिज़ाइन के रूप में, बहु-किरायेदार एप्लिकेशन को डिज़ाइन करते समय ध्यान में रखना कई चीजें हैं, लेकिन लाइसेंस लागत, स्केलेबिलिटी इत्यादि जैसी चीजों को भी ध्यान में रखा जाना चाहिए। पेशेवरों और विपक्ष सहित This article describes the three most common approaches for designing a multi-tenant application। इसकी जांच - पड़ताल करें।

+1

उत्तर के रूप में चिह्नित किया गया, क्योंकि आपके लिंक ने मुझे सबसे अधिक जानकारी दी है। मैं अभी भी तय नहीं कर सकता कि क्या करना है। मैं कई किरायेदारों के लिए एक डीबी डिजाइन करना शुरू कर दूंगा, क्योंकि अलग-अलग डीबी में इसे बदलना आसान है, अगर मैं अपना दिमाग बदलता हूं, तो एक डीबी डिज़ाइन में पृथक डीबी को फिर से डिजाइन करना है। – Batibix

+0

वह लिंक वास्तव में बहुत अच्छा था। मैंने बहुत कुछ सीखा। यह सास के निर्माण पर एक पुस्तक का हिस्सा होना चाहिए जो मैं शायद खरीदूँगा। – racl101

+2

वास्तव में आप चाहते हैं कि आप उस लेख का मांस यहां पोस्ट करें, क्योंकि अब यह एक मृत उत्तर है जो लिंक-रोट के लिए धन्यवाद। –

2

आईएमएचओ केवल एक ही रास्ता है। एकाधिक डेटाबेस

  1. इतना ही नहीं पूरी तरह से सुरक्षित डेटा है कि कभी नहीं साझा किया जाना चाहिए
  2. यह भी एक दूसरे से स्वतंत्र बदलने के लिए स्कीमा के लिए सक्षम बनाता है। इसके द्वारा मेरा मतलब है कि समय के साथ, शायद एक किरायेदार अन्य सभी टीनेंटों की तुलना में बहुत बड़ा है, और इस प्रकार विशेष जरूरतों को पूरा किया जाना चाहिए।
  3. बैकअप, संचालन बहाल करने और रणनीतियों आसानी से स्वतंत्र डेटाबेस
  4. प्रतिबन्ध और विशिष्टता के लिए तैयार किया जा सकता आसान कर रहे हैं और अधिक स्वाभाविक रूप
+1

मैं बिना किराये के प्रति किरायेदार स्वतंत्र स्कीमा प्राप्त नहीं कर पाऊंगा डाइविंग ऐप संस्करण इत्यादि के साथ एक रखरखाव दुःस्वप्न में – Batibix

+0

आपको अभी भी 1 + 3 + 4 –

+1

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

5

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

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

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

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

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

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

+0

यदि आपके पास ऐसा टूल है जो कॉन्फ़िगरेशन-फ़ाइल का उपयोग करके डीबी को स्थापित करने का ख्याल रखता है तो यह एक समस्या से कम हो जाता है –

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