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