आपके द्वारा प्रदान की गई जानकारी के आधार पर, मैं एक ही नींव से शुरू होने वाले दो संभावित तरीकों की सिफारिश करूंगा:
मैं इस दृष्टिकोण की अनुशंसा करता हूं यदि:
- आपके पास लेख दस्तावेज़ों के साथ-साथ प्लेटफ़ॉर्म दोनों की उच्च कार्डिनैलिटी है
-
आप दोनों संस्थाओं के बीच संदर्भों को समन्वयित करते हुए स्वतंत्र रूप से प्रबंधित करने में सक्षम होना चाहते हैं
// articles collection schema { "_id": ..., "title": "I am an article", ... "platforms": [ "platform_1", "platform_2", "platform_3" ], ... } // platforms collection schema { "_id": "platform_1", "name": "Platform 1", "url": "http://right/here", ... }, { "_id": "platform_2", "name": "Platform 2", "url": "http://right/here", ... }, { "_id": "platform_3", "name": "Platform 3", "url": "http://right/here", ... }
यहां तक कि अगर यह दृष्टिकोण काफी लचीला है, तो यह एक लागत पर आता है - यदि आपको लेख और प्लेटफ़ॉर्म डेटा दोनों की आवश्यकता है, तो आपको अपने MongoDB उदाहरण के लिए और अधिक प्रश्नों को आग लगाना होगा, क्योंकि डेटा दो अलग-अलग संग्रहों में विभाजित है।
उदाहरण के लिए, लेख पृष्ठ लोड करते समय, यह मानते हुए कि आप platforms की सूची भी प्रदर्शित करना चाहते हैं , आपको articles collection . के लिए एक क्वेरी सक्रिय करनी होगी , और फिर platforms collection . पर एक खोज भी ट्रिगर करें platforms . के सदस्यों के माध्यम से उन सभी प्लेटफ़ॉर्म इकाइयों को पुनः प्राप्त करने के लिए जिन पर वह लेख प्रकाशित किया गया है article document पर s सरणी ।
हालांकि, यदि आपके पास बार-बार एक्सेस किए जाने वाले platform attributes . का केवल एक छोटा उपसमुच्चय है article document loading लोड करते समय आपको उपलब्ध होना चाहिए , आप platforms को बेहतर बना सकते हैं articles collection पर सरणी _id . के अतिरिक्त उन विशेषताओं को संग्रहीत करने के लिए प्लेटफ़ॉर्म दस्तावेज़ों का संदर्भ:
// enhanced articles collection schema
{
"_id": ...,
"title": "I am an article",
...
"platforms": [
{platform_id: "platform_1", name: "Platform 1"},
{platform_id: "platform_2", name: "Platform 2"},
{platform_id: "platform_3", name: "Platform 3"}
],
...
}
यह हाइब्रिड दृष्टिकोण उपयुक्त होगा यदि platform data attributes जिसे आप अक्सर लेख विशिष्ट डेटा के साथ प्रदर्शित करने के लिए पुनर्प्राप्त करते हैं, वह अक्सर नहीं बदल रहा है।
अन्यथा, आपको platform document attributes . में किए गए सभी अपडेट को सिंक्रनाइज़ करना होगा platforms collection . में उन विशेषताओं के सबसेट के साथ जिन्हें आप लेख दस्तावेज़ों के लिए प्लेटफ़ॉर्म सरणी के हिस्से के रूप में ट्रैक करते हैं।
अलग-अलग प्लेटफार्मों के लिए लेख सूचियों के प्रबंधन के संबंध में, मैं दोनों संग्रहों में एन-टू-एन संदर्भों को संग्रहीत करने की अनुशंसा नहीं करता, क्योंकि उपरोक्त तंत्र आपको पहले से ही articles collection को क्वेरी करके लेख सूचियों को निकालने की अनुमति देता है। _id . के साथ खोज क्वेरी का उपयोग करना platform document का मान :
Approach #1
db.articles.find({"platforms": "platform_1"});
Approach #2:
db.articles.find({"platforms.platform_id": "platform_1"});
दो अलग-अलग दृष्टिकोण प्रस्तुत करने के बाद, अब मैं आपको अपने आवेदन के क्वेरी पैटर्न और प्रदर्शन सीमा का विश्लेषण करने और आपके सामने आने वाले परिदृश्यों के आधार पर एक परिकलित निर्णय लेने की सलाह दूंगा।
