यहाँ कुछ विचार हैं। अंत में, यह आपकी आवश्यकताओं पर निर्भर करता है:
-
रेटिंग वैकल्पिक है, है ना?
यदि ऐसा है, तो अपने आप से पूछें कि क्या आप एक आवश्यक विशेषता (शिक्षक/छात्र संघ का भंडारण) को एक अच्छी सुविधा के साथ जोड़ना चाहते हैं। एक अच्छी सुविधा को लागू करने वाला कोड अब आपके सबसे महत्वपूर्ण संग्रह को लिखता है। मुझे लगता है कि आप अपने कोड में चिंताओं को अलग करना improve में सुधार कर सकते हैं एक अलग डीबी स्कीमा के साथ।
-
क्या आपको अधिक सुविधाओं की आवश्यकता होगी ?
मान लें कि आप छात्रों को उनके द्वारा दी गई रेटिंग की एक सूची प्रदान करना चाहते हैं, एक छात्र द्वारा शिक्षकों को दी गई औसत रेटिंग, और आप समय के साथ रेटिंग का विकास दिखाना चाहते हैं। यह एम्बेडेड दस्तावेज़ों के साथ बहुत गड़बड़ होगा। एम्बेडेड दस्तावेज़ कम लचीले होते हैं ।
-
यदि आपको शीर्ष पठन प्रदर्शन की आवश्यकता है, तो आपको अधिक डेटा को सामान्य बनाने की आवश्यकता है
यदि आप एम्बेडेड दस्तावेज़ों से चिपके रहना चाहते हैं, तो हो सकता है कि आप अधिक डेटा कॉपी करना चाहें। मान लें कि प्रति शिक्षक रेटिंग का एक सिंहावलोकन है जहां आप छात्रों के नाम देख सकते हैं। किसी वस्तु को एम्बेड करना उपयोगी होगा
{ studentId : ObjectId, rating: string, studentName: string, created: dateTime }
विकल्प के रूप में, विचार करें
TeacherRating {
StudentId: id
TeacherId: id
Rating: number
Created: DateTime
}
शिक्षक/छात्र संघ अभी भी शिक्षक ऑब्जेक्ट में संग्रहीत किया जाएगा, लेकिन रेटिंग एक अलग संग्रह में हैं। यदि शिक्षक और छात्र के बीच कोई संबंध नहीं पाया जा सकता है तो रेटिंग नहीं बनाई जा सकती।
या
TeacherStudentClass {
StudentId: id
TeacherId: id
Class: id
ClassName: string // (denormalized, just an example)
Rating: number // (optional)
Created: DateTime
}
किसी दिए गए शिक्षक के लिए सभी छात्रों को खोजने के लिए, आपको पहले लिंकर दस्तावेज़ को क्वेरी करना होगा, फिर एक $in
करना होगा छात्रों पर सवाल, और इसके विपरीत। यह एक और प्रश्न है, लेकिन यह लचीलेपन में भारी लाभ के साथ आता है।