Hoe moet de volgende veel-op-veel-relatie worden gemodelleerd in MongoDB?

Hier zijn enkele overwegingen. Uiteindelijk hangt het af van uw vereisten:

1. Beoordeling is optioneel, toch?

   Vraag je dan af of je een verplichte functie (opbergen docent/studentenvereniging) wilt combineren met een leuke functie. Code die een leuke functie implementeert, schrijft nu naar uw belangrijkste verzameling. Ik denk dat je de scheiding van zorgen in je code kunt verbeteren met een ander db-schema.

2. Heb je meer functies nodig? ?

   Stel dat u leerlingen een lijst wilt geven met beoordelingen die ze hebben gegeven, de gemiddelde beoordeling die een leerling aan docenten heeft gegeven en dat u een ontwikkeling van de beoordelingen in de loop van de tijd wilt laten zien. Dit zal erg rommelig zijn met ingesloten documenten. Ingesloten documenten zijn minder flexibel .

3. Als u de beste leesprestaties nodig heeft, moet u meer gegevens denormaliseren

   Als u zich wilt houden aan de ingesloten documenten, wilt u misschien meer gegevens kopiëren. Laten we zeggen dat er een overzicht is van beoordelingen per docent waar je de namen van de studenten kunt zien. Het zou handig zijn om een ​​object in te sluiten

   { studentId : ObjectId, 
     rating: string, 
     studentName: string, 
     created: dateTime }
   

Overweeg als alternatief

TeacherRating {
    StudentId: id
    TeacherId: id
    Rating: number
    Created: DateTime
}

Docent/studentenvereniging wordt nog steeds opgeslagen in het docentobject, maar de beoordelingen bevinden zich in een andere verzameling. Er kan geen beoordeling worden gemaakt als er geen verband tussen docent en leerling kan worden gevonden.

of

TeacherStudentClass {
    StudentId: id
    TeacherId: id
    Class: id
    ClassName: string // (denormalized, just an example)
    Rating: number // (optional)
    Created: DateTime
}

Om alle studenten voor een bepaalde leraar te vinden, moet je eerst het linkerdocument opvragen en vervolgens een $in doen vragen over de leerlingen en vice versa. Dat is nog een vraag, maar het gaat gepaard met een enorme winst in flexibiliteit.