Как организовать много-много отношений в MongoDB

У меня есть две таблицы/коллекции; Пользователи и группы. Пользователь может быть членом любого количества групп, и пользователь также может быть владельцем любого количества групп. В реляционной базе данных у меня, вероятно, будет третья таблица UserGroups с столбцом UserID, столбцом GroupID и столбцом IsOwner.

Я использую MongoDB, и я уверен, что существует другой подход для такого рода отношений в базе данных документов. Должен ли я встраивать список групп и групп как владельца в таблицу Users как два массива ObjectID? Должен ли я также хранить список участников и владельцев в таблице "Группы" в виде двух массивов, эффективно отражающих отношения, вызывающие дублирование информации о взаимоотношениях?

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

Спасибо

Ответ 1

То, что я видел, и что я сейчас использую, - это встроенные массивы с идентификатором node в каждом документе.

Итак, у документа user1 есть группы свойств: [id1, id2]

И у документа group1 есть пользователи свойств: [user1]. У документа group2 также есть пользователи свойств: [user1].

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

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

Существует также концепция DBReferences в MongoDB и в зависимости от вашего драйвера, она автоматически вытаскивает ссылочные объекты при извлечении документа.

http://www.mongodb.org/display/DOCS/Database+References#DatabaseReferences-DBRef

Ответ 2

Позвольте понять многие для многих отношений с примерами

книги авторам
студенты-преподаватели.

Книги для авторов - это отношения от нескольких до нескольких, поэтому мы можем иметь либо массив книг, либо авторов внутри другого документа. То же самое касается учеников для учителей. Мы могли бы также внедрить риск дублирования. Однако это потребует, чтобы каждый ученик имел учитель в системе перед вставкой и наоборот. Логика приложения всегда может не допускать этого. Другими словами, родительский объект должен существовать для существования дочернего объекта.

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

Ответ 3

В случае, если кто-то заинтересован, я просто столкнулся с очень хорошей статьей, размещенной в блоге mongoDB. 6 правил большого пальца для схемы схемы MongoDB. В этой статье есть 3 части, после прочтения всех 3 у вас будет хорошее понимание.