Hier einige Überlegungen. Am Ende hängt es von Ihren Anforderungen ab:
-
Die Bewertung ist optional, richtig?
Wenn ja, fragen Sie sich, ob Sie ein erforderliches Feature (Speichern der Lehrer/Schüler-Verbindung) mit einem Nice-to-have kombinieren möchten. Code, der ein Nice-to-have-Feature implementiert, schreibt jetzt in Ihre wichtigste Sammlung. Ich denke, Sie können die Trennung von Bedenken in Ihrem Code verbessern mit einem anderen DB-Schema.
-
Benötigen Sie mehr Funktionen? ?
Angenommen, Sie möchten den Schülern eine Liste der Bewertungen, die sie abgegeben haben, die durchschnittliche Bewertung, die ein Schüler den Lehrern gegeben hat, zur Verfügung stellen, und Sie möchten die Entwicklung der Bewertungen im Laufe der Zeit anzeigen. Dies wird bei eingebetteten Dokumenten sehr chaotisch. Eingebettete Dokumente sind weniger flexibel .
-
Wenn Sie eine Top-Leseleistung benötigen, müssen Sie mehr Daten denormalisieren
Wenn Sie sich an die eingebetteten Dokumente halten möchten, möchten Sie möglicherweise mehr Daten kopieren. Angenommen, es gibt eine Übersicht der Bewertungen pro Lehrer, in der Sie die Namen der Schüler sehen können. Es wäre hilfreich, ein Objekt einzubetten
{ studentId : ObjectId, rating: string, studentName: string, created: dateTime }
Betrachten Sie als Alternativen
TeacherRating {
StudentId: id
TeacherId: id
Rating: number
Created: DateTime
}
Die Lehrer/Schüler-Verbindung wird weiterhin im Lehrerobjekt gespeichert, aber die Bewertungen befinden sich in anderen Sammlungen. Eine Bewertung kann nicht erstellt werden, wenn keine Zuordnung zwischen Lehrer und Schüler gefunden werden kann.
oder
TeacherStudentClass {
StudentId: id
TeacherId: id
Class: id
ClassName: string // (denormalized, just an example)
Rating: number // (optional)
Created: DateTime
}
Um alle Schüler für einen bestimmten Lehrer zu finden, müssten Sie zuerst das Linker-Dokument abfragen und dann einen $in ausführen Abfrage der Schüler und umgekehrt. Das ist eine weitere Abfrage, aber mit einem enormen Gewinn an Flexibilität.
