एक user कई projects हो सकते हैं (और एक प्रोजेक्ट केवल एक उपयोगकर्ता के साथ जुड़ा हुआ है)। यह एक एक से अनेक है संबंध।
प्रत्येक user अपने projects . की सूची को संगृहीत करना चाहिए . उदाहरण के लिए:
user:
id: <some value>,
name: <some value>,
email: <some value>,
projects: [
{ projectId: <some value>, projectName: <...>, projectDescription: <....>, otherInfo: { fld1: <...>, fld2: <...>, etc. } },
{ projectId: <some value>, projectName: <...>, projectDescription: <....>, otherInfo: { fld1: <...>, fld2: <...>, etc. } },
...
]
ध्यान दें कि प्रत्येक projects projects . के भीतर एक उप-दस्तावेज़ (वस्तु या एम्बेडेड दस्तावेज़) है सरणी। एक projects इसके संबंधित विवरण हैं, जैसे, projectId , projectName , आदि..
मुझे लगता है, केवल एक संग्रह होना चाहिए जिसे user_projects . कहा जाता है . यह मानते हुए कि:(i) एक user 0 से 100 प्रोजेक्ट हो सकते हैं, और (ii) एक projects का विवरण बहुत बड़ा नहीं है।
यह 1-से-N संबंध के 'कई' पक्षों को 'एक' पक्ष में एम्बेड करने का एक मॉडल है। यह एक अनुशंसित तरीका है, डेटा को सामान्य बनाना। इसका कुशल और तेज़ प्रश्नों का लाभ है। यह लेन-देन को सरल करता है, जैसा कि लिखता है (सम्मिलित करता है, अद्यतन करता है और हटाता है) एक ही संग्रह के भीतर एक दस्तावेज़ के लिए एकल ऑपरेशन के साथ परमाणु होने जा रहा है।
आप user . का उपयोग कर रहे होंगे id या name (एक अद्वितीय अनुक्रमणिका के साथ) किसी दस्तावेज़ को पुनर्प्राप्त करने के लिए, और यह बहुत तेज़ क्वेरी होगी। आपके पास projects . पर अनुक्रमणिका हो सकती है सरणी (सरणी फ़ील्ड पर अनुक्रमणिका को बहुकुंजी अनुक्रमणिका . कहा जाता है) ) - परियोजना के क्षेत्रों पर। उदाहरण के लिए, projectId . पर अनुक्रमणिका या/और projectName समझ में आता है।
आप किसी उपयोगकर्ता के लिए सभी प्रोजेक्ट प्राप्त कर सकते हैं - यह user . का उपयोग करके एक साधारण क्वेरी है id / name . क्वेरी प्रक्षेपण projects . से संबंधित कौन सी जानकारी देता है यह प्रदर्शित है। आप एक find . का उपयोग कर सकते हैं या aggregate क्वेरी बनाने की विधि। आप किसी विशिष्ट projects . को क्वेरी कर सकते हैं एक user . के लिए , projectId . का उपयोग करके या projectName . चूंकि user . पर अनुक्रमणिकाएं हैं और projects फ़ील्ड, यह एक कुशल क्वेरी होगी।
तो, मेरी सिफारिश है कि एक ही संग्रह हो, user_projects , एक user . के साथ की जानकारी और projects इसमें निहित जानकारी।
