2016-04-28 15 views
6

मोंगो से पॉचडब (क्लाउडेंट के साथ) में स्विचिंग, मुझे "प्रति उपयोगकर्ता एक डेटाबेस" अवधारणा पसंद है, लेकिन क्या प्रति डेटाबेस एकाधिक संग्रह/तालिकाओं को बनाने का कोई तरीका है?क्या मैं प्रति डेटाबेस एकाधिक संग्रह बना सकता हूं?

उदाहरण

- Peter 
     - History 
     - Settings 
     - Friends 
- John 
     - History 
     - Settings 
     - Friends 

आदि ...

धन्यवाद

उत्तर

10

CouchDB संग्रह की अवधारणा नहीं है। हालांकि, आप Couchdb विचारों के संयोजन के साथ अपने दस्तावेज़ों पर प्रकार पहचानकर्ताओं का उपयोग करके समान परिणाम प्राप्त कर सकते हैं।

प्रकार पहचानकर्ता

आप एक क्षेत्र है कि प्रकार निर्दिष्ट जोड़ने CouchDB में कोई दस्तावेज़ सहेजते हैं। उदाहरण के लिए, यदि आप ऐसा तरह एक दोस्त की दुकान होगा:

{ 
    _id: "XXXX", 
    type: "Friend", 
    first_name: "John", 
    ... 
} 

और तुम इस तरह इतिहास को संग्रहीत होगा:

{ 
    _id: "XXXX", 
    type: "History", 
    url: "http://www.google.com", 
    ... 
} 

इन दस्तावेजों की दोनों एक ही डेटाबेस में हो सकता है, और यदि आप सभी दस्तावेजों पूछे उस डेटाबेस पर आप दोनों प्राप्त करेंगे।

दृश्य

आप को देखता है प्रकार पर और उसके बाद फिल्टर करके उन दृश्यों सीधे क्वेरी बना सकते हैं। उदाहरण के लिए, तो जैसे मित्रों को प्राप्त करने के लिए एक दृश्य बनाने के (Cloudant में आप नए डिजाइन दस्तावेज़ जोड़ने के लिए जा सकते हैं और आप कॉपी कर सकते हैं और इस सीधे पेस्ट):

function(doc) { 
    if (doc.type && doc.type == "Friend") { 
    emit(doc._id, doc._rev); 
    } 
} 
:

{ 
    "_id" : "_design/friends", 
    "views" : { 
    "all" : { 
     "map" : "function(doc){ if (doc.type && doc.type == 'Friend') { emit(doc._id, doc._rev)}}" 
    } 
    } 
} 

के मानचित्र समारोह का विस्तार करते हैं

अनिवार्य रूप से यह नक्शा फ़ंक्शन केवल इस दृश्य में दस्तावेज़ों को संबद्ध करने के लिए कह रहा है जिसमें टाइप == "मित्र" है। अब, हम इस दृश्य को क्वेरी कर सकते हैं और केवल मित्र लौटा दी जाएगी:

http://SERVER/DATABASE/_design/friends/_view/all 

कहाँ friends = डिजाइन दस्तावेज़ और all = दृश्य का नाम का नाम है। अपने सर्वर नाम के साथ SERVER और अपने डेटाबेस नाम के साथ DATABASE बदलें।

आप यहाँ विचारों के बारे में अधिक जानकारी प्राप्त कर सकते हैं:

https://wiki.apache.org/couchdb/Introduction_to_CouchDB_views

3

आप कुछ इस तरह के लिए relational-pouch पर गौर कर सकता है। अन्यथा आप "प्रति उपयोगकर्ता 3 डेटाबेस" कर सकते हैं। ;)

0

मैं पूरी तरह से समझ नहीं पा रहा हूं कि आपको यहां क्या चाहिए लेकिन आम तौर पर आप कोचडीबी/क्लाउडेंट/पाउचडीबी में 3 अलग-अलग तरीकों से जो वर्णन करते हैं, उसे प्राप्त कर सकते हैं।

  1. प्रति व्यक्ति एकल दस्तावेज़ (पीटर, जॉन)।निश्चित रूप से - यदि संग्रह अलग-अलग नहीं हैं और अधिक महत्वपूर्ण रूप से यदि वे अलग-अलग उपयोगकर्ताओं द्वारा समेकित रूप से अपडेट नहीं किए जाते हैं (या विभिन्न डेटाबेस उदाहरणों में बदतर) तो संघर्षों की ओर अग्रसर होते हैं, तो JSON में प्रत्येक संग्रह के लिए केवल एक तत्व होता है, जिसमें एक सरणी होती है और आप सब कुछ कुशल बना सकते हैं सिर्फ एक दस्तावेज़ के साथ। एक हवा का उपयोग करता है।
  2. प्रति संग्रह एकल दस्तावेज़ (पीटर इतिहास, पीटर सेटिंग्स ect)। इसी तरह की बाधाएं, लेकिन आप इनमें से प्रत्येक संग्रह को पकड़ने के लिए एक दस्तावेज़ बना सकते हैं। बशर्ते वे अक्सर समवर्ती रूप से संशोधित नहीं होंगे, फिर आपके पास पीटर के इतिहास के लिए एक दस्तावेज़ होगा, और दूसरा पीटर की सेटिंग्स के लिए होगा।
  3. प्रति आइटम एकल दस्तावेज़। यह बेहतरीन अनाज दृष्टिकोण है - बहुत से छोटे सरल दस्तावेज़ जिनमें प्रत्येक तत्व होता है (पीटर के लिए एक एकल इतिहास प्रविष्टि कहें)। कोड थोड़ा आसान हो जाता है क्योंकि आइटम को हटाने से हटा दिया जाता है और कई ग्राहक एक साथ आइटम अपडेट कर सकते हैं, लेकिन अब आप सभी वस्तुओं को एक सूची में लाने के लिए दृश्यों पर निर्भर करते हैं। उदाहरण के लिए कुंजी [व्यक्ति, सूची नाम, आइटम] के साथ एक दृश्य आपको इच्छित चीज़ों तक पहुंचने देगा।

आम तौर पर आपके डेटा स्कीमा निर्णय समेकन के लिए नीचे आते हैं। आप पाउचडीबी का जिक्र करते हैं, तो हो सकता है कि आपके पास एक थ्रेडेड क्लाइंट हो और विकल्प 1 अच्छा और आसान हो?

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