2012-06-06 1 views
2

Предположим, у меня есть Студент и Учитель во многих отношениях. Если я просто хочу узнать всех учителей для данного учащегося или наоборот, я вообще моделирую его с помощью встроенных идентификаторов объектов. Например, если у преподавателя есть свойство studentIds, которое является массивом идентификаторов Object для учащихся, тогда это достаточно информации для выполнения всех запросов.Каким образом в MongoDB должно быть смоделировано следующее много-много отношений?

Однако предположим, что студент может дать учителю оценку. Как этот рейтинг должен соответствовать модели? На данный момент я делаю следующее:

  1. Внутри учителя вместо того, чтобы хранить массив студента, я хранить массив JSON объектов {studentId: ObjectId, рейтинг: String}
  2. При выполнении запроса, я преобразовать массив объектов JSON в массив из studentIds и извлечь полную информацию, как обычно
  3. Так что теперь у меня есть массив студенческих объектов и массив объектов JSON с на рейтинги
  4. Однако, поскольку $ в оператор в MongoDB не сохраняет порядок, мне нужно сделать мой п сортировка
  5. На последнем этапе, со всем, чтобы я могу объединить студент объекты с рейтингами , чтобы получить то, что я хочу

Это работает, но кажется несколько запутанными есть лучший способ сделать это?

+0

Кажется разумным для меня .... –

ответ

1

Вот некоторые соображения. В конце концов, это зависит от ваших требований:

  1. Оценка не является обязательной, верно?

    Если да, спросите себя, хотите ли вы объединить требуемую функцию (сохранение ассоциации учителей/учеников) с красивой. Код, который реализует функцию nice-to-have, теперь записывается в вашу самую важную коллекцию. Я думаю, вы можете улучшить разделение проблем в вашем коде с другой схемой db.

  2. Вам понадобится Дополнительные функции?

    Предположим, вы хотите предоставить студентам список рейтингов, которые они дали, средний рейтинг, который студент дал преподавателям, и вы хотите показать развитие рейтингов с течением времени. Это будет очень грязно со встроенными документами. Вложенные документы менее гибкие.

  3. Если вам нужна максимальная производительность чтения, вам необходимо денормализовать больше данных

    Если вы хотите придерживаться вложенных документов, вы можете скопировать больше данных. Предположим, есть обзор рейтингов на одного преподавателя, где вы можете увидеть имена учеников.Было бы полезно, чтобы внедрить объект

    { 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 запрос на студентах, и наоборот. Это еще один запрос, но он имеет огромный выигрыш в гибкости.

Смежные вопросы