Годится ли такое проектирование в mongodb?

Question

[philatov182]

Имеется такая бд в реляционном виде. Пытаюсь ее подвести к формату mongodb. Подскажите как лучше спроектировать такую бд в mongo. Не пойму, как правильно хранить оценки по дисциплине у студента?

У меня получилось так:

student
{
      _id: ..,
      lname: ..,
      fname: ..,
      mname: ..,
      passport: { num: .., seria: ..},
      attests: [
             { discname: .., mark: ..},
             { .. }, ..
      ]
}

group
{
      _id: ..,
      num: ..,
      students: [
             ObjectId(..), ..
      ],
      disciplines: [
             ObjectId(..), ..
      ],
}

discipline
{
      _id: ..,
      name: ..,
      groups: [
             ObjectId(..), ..
      ],
}

Answer 1

[Frozen Coder]

Тут всё зависит от того, как эти данные будут использоваться.
Если нам в первую очередь важен пользователь, то может вообще всё в него запихать.
Переносить схему один в один - это такое себе занятие. Вы какую проблему этим решаете? Если вам отношения между сущностями важны и вы хотите их со всех сторон использовать, то может не есть кактус и взять реляционную БД?

Comments

[philatov182]

Задачка учебная и придумана для того, чтобы собственно разобраться как будет выглядеть бд в mongodb. Если всё запихать в student будет очень много дублирования данных и это неверно я считаю.

[Frozen Coder]

philatov182, смотря какого дублирования. Это дублирование будет меняться или нет? Если нет, то мб и чёрт с ним? А может быть всё таки задача не совсем подходит под монгу и вы пытаетесь натянуть сову на глобус? Монго это документо-ориентированная база данных. В ней главное документ, а не его связи. Она другие проблемы решает.

Ещё почитайте гайды по проектированию данных в монго, вроде в доках были и официальные статьи тоже.

[philatov182]

Frozen Coder, есть 2 подхода к проектированию как я понял: embedded и referenced. Вот их я и применил. Referenced используется всегда, когда many to many. Embedded используется всегда, когда one to one. Как лучше так и не могу понять. Подскажите где можно найти(киньте ссылку) примеры бд на mongo, где коллекций 5 хотя бы есть, а то везде примеры 1-2 коллекции

[Frozen Coder]

philatov182, А потому что не пляшут тут в монге от отношений (отношения - это реляционные БД) и чем отношений меньше, тем лучше. А идут от того, как данные будут использоваться. И тут наоборот денормализация данных. Но вы в принципе правильно поняли про embedded и referenced, просто пример не слишком удачный.

Надо отталкиваться от проблемы, от того, как именно будут использоваться данные. Примеры:
Если пользователь главная фигура, то всё по максимуму запихиваем в него. Пусть какое-то дублирование (если не будет никаких обновлений, то можно закрыть на это глаза), но никаких join и доп. запросов. Сразу достали и работаем.
А если мы делаем какую-нибудь ведомость по оценкам, то тут надо плясать от оценок. Тогда можно сделать коллекцию оценок, которая будет хранить оценку и ссылки на пользователей и дисциплину.

Из моего опыта применения монги всегда в бд был одина-две коллекции основных документов и коллекции справочников, которые с ними связаны. И никаких циклических зависимостей.

Можете погуглить "mongodb data modeling best practices".

Вот тут я отвечал, зачем и когда используют монгу

[philatov182]

Frozen Coder, подскажи как профайлером пользоваться. Коллекции system.profile вообще нет, в чем проблема не пойму