बहु-उपयोगकर्ता

Question

के लिए कॉच डीबी मॉडलिंग मैं दस्तावेज़ डेटाबेस और विशेष रूप से कॉच डीबी की सादगी के बारे में उत्साहित हूं। लेकिन मुझे समझने में कठिनाई हो रही है कि ऐसे डेटाबेस बहु उपयोगकर्ता सिस्टम के लिए व्यवहार्य विकल्प हैं। चूंकि उन प्रणालियों के रिकॉर्ड के बीच कुछ प्रकार के संबंधों की आवश्यकता होती है जो दस्तावेज़ डेटाबेस प्रदान नहीं करते हैं।

क्या यह ऐसे मामलों के लिए पूरी तरह से गलत उपकरण है? या कुछ टैगिंग और अस्थायी विचार इसे पूरा करने का तरीका हैं? अन्यथा ...

अद्यतन:
अब तक मैं जवाबों को समझता हूं। लेकिन मुझे सवाल थोड़ा सा दोहराएं। आइए कहें कि मेरे पास अर्ध-संरचित डेटा का भार है जो आमतौर पर कॉच डीबी के लिए उपयुक्त है। मैं उन्हें "टाइप = पोस्ट" और "वर्ष = 2008" जैसे टैग कर सकता हूं। मेरा सवाल यह है कि मैं इस प्रकार के टैगिंग के साथ कितना दूर जा सकता हूं? क्या मैं इसमें 10.000 नामों के साथ एक सरणी फ़ील्ड बना सकता हूं? या यह करने का एक बेहतर तरीका है? यह समझने की बात है कि इस दस्तावेज़ आधारित अर्थ में कैसे सोचें।

Answer 1

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

तो बहु-उपयोगकर्ता प्रणाली के मामले में एसीएल आधारित अनुमतियों को लागू करने का एक तरीका 'अनुमति दस्तावेज़' बनाना हो सकता है जो कि उपयुक्त अनुमति के साथ doc_id पर user_id का मैपिंग होगा।

{ 
    _id: "permission_doc_1", 
    type: "acl", 
    user: "John", 
    docid: "John's Account Info", 
    read: true, 
    write: true 
} 

और अपने विचार

function(doc) 
{ 
    emit([doc.user, doc.docid], {"read": doc.read, "write": doc.write}); 
} 

की तर्ज पर कुछ हो और एक DocID और उपयोगकर्ता आईडी दिया जाएगा, अनुमतियों के लिए जाँच होगी:

http://localhost:5984/db/_view/permissions/all?key=["John", "John's Account Info"] 

जाहिर है, इस के होने की आवश्यकता होगी यह सुनिश्चित करने के लिए कि अनुमतियां लागू की गई थी, ग्राहक और सोफे के बीच कुछ मध्यस्थ।

Answer 2

मल्टी-उपयोगकर्ता सिस्टम संबंधपरक डेटाबेस की आवश्यकता नहीं है, हालांकि आरडीबीएमएस डेटा संग्रहण/पुनर्प्राप्ति के लिए एक बड़ी संख्या (विशेष रूप से सीआरयूडी) अनुप्रयोगों के लिए एक प्रमुख तकनीक है।

यदि आप दस्तावेज़/ऑब्जेक्ट-आधारित, वितरित डेटाबेस समाधान पर पढ़ना चाहते हैं, तो "लोटस नोट्स/डोमिनोज़" पर खोजें (यह इस क्षेत्र में एक परिपक्व तकनीक/उत्पाद है जो अनुप्रयोगों के बारे में अच्छी पृष्ठभूमि जानकारी है दस्तावेज़-आधारित प्रतिमान में डिज़ाइन किया गया। क्लासिकल, वर्कफ़्लो प्रकार अनुप्रयोगों में यह वास्तव में अच्छा है)।

CouchDB पर विशेष रूप से, बाहर की जाँच:

http://wiki.apache.org/couchdb/ (यह एक आश्चर्य नहीं होना चाहिए)

http://seanoc.wordpress.com/2007/10/12/more-on-couchdb/ (आसानी से पढ़ने वर्णन सिंहावलोकन)

http://twit.tv/floss36 (सब के बारे में CouchDB पॉडकास्ट साक्षात्कार)

Answer 3

क्या @micahwittman कहते हैं। बस एक त्वरित जोड़: उत्पादन प्रणाली में अस्थायी विचारों का कभी भी उपयोग नहीं किया जाना चाहिए, वे केवल विकास के लिए हैं। स्थायी विचार सब कुछ कर सकते हैं अस्थायी विचार कर सकते हैं और तेजी से बढ़ रहे हैं।