Многие ко многим в БД документов

Я только начинаю с MongoDB (Поздно на вечеринку, я знаю ...)

Я все еще пытаюсь выбросить из головы 10+ лет реляционной БД, когда думаю о дизайне документа.

Допустим, у меня много пользователей, использующих множество приложений. Любой пользователь может использовать несколько приложений, и любое приложение может использовать любое количество пользователей.

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

Мне просто нужно иметь дубликаты данных? Может быть, у вас есть массив пользователей в документе App и массив приложений в пользовательском документе? Имеет ли это смысл? Является ли это обычным подходом к базам данных документов?


mongodb document-database
person Elad Lachmi    schedule 14.05.2014    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Согласно вашему сценарию, вам не нужно иметь повторяющиеся данные. Поскольку это взаимосвязь «многие ко многим» и данные будут постоянно меняться, вам необходимо использовать ссылку на документ вместо встраивания документа.

Итак, у вас будет две коллекции:

коллекция приложений:

{
     _id : appId,
    app_name : "appname",
    // other property of app
    users : [userid1, userid2]

}

Коллекция пользователей:

{
      _id : userId,
      // other details of user
     apps: [appid1, appid2, ..]

}

Как вы упомянули, вам необходимо иметь массив пользователей в коллекции приложений и массив приложений в коллекции пользователей.

Когда вы получаете данные в клиенте, сначала, когда пользователь входит в систему, вы получите массив идентификаторов приложений из пользовательского документа.

Опять же, с идентификаторами приложений вам нужно запросить сведения о приложениях в коллекции приложений.

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

Это обычное явление в mongodb для отношений "многие ко многим".

person mohamedrias    schedule 14.05.2014
comment
Спасибо. Это именно то, что я имел в виду. Я просто хотел проверить, был ли это принятый шаблон для использования mongodb. - person Elad Lachmi; 17.05.2014

arrow_upward
2
arrow_downward

Хороший вопрос!

У вас есть сценарий "многие ко многим". В Mongo вы можете решить эту проблему разными способами: с помощью таблицы поиска, как в SQL, или с помощью массива. Вам следует учитывать индексы, такие же, как в SQL, но на этот раз у вас есть больше возможностей. Поскольку это сценарий «многие ко многим», я, вероятно, выбрал бы таблицу поиска. Это наиболее эффективный способ привлечь пользователей приложения и приложений пользователя. Массив не подходит для динамических значений, особенно если вам нужны два поля массива (приложение / пользователь), в то время как поле массива app.users будет часто меняться. Обратной стороной является то, что вы можете «присоединиться» и вам придется «выбирать» данные из двух таблиц и выполнять «соединение» самостоятельно, но это не должно быть проблемой, тем более что вы всегда можете кэшировать результат (локальное кеширование в вашем приложении ) и Mongo вернет результат очень быстро, если вы добавите индекс для пользовательского поля

{
_id: "<appID>_<userID>" ,
user: "<userID>"
}

_id индексы по умолчанию. Другой индекс должен быть создан для поля "user", тогда Mongo загрузит btree в память, и все в порядке.

person Nikita 웃    schedule 14.05.2014