Каков наилучший подход для хранения двух списков одного типа в mongoDB?

Question

Мне интересно с точки зрения дизайна базы данных, каков наилучший подход к сохранению ссылочного идентификатора или внедренного документа, даже если это означает, что несколько документов могут появляться более одного раза.

Допустим, у меня есть такоймодели на данный момент:

Пользователь коллекции:

{
    name: String,  
    types : List<Type> 
    sharedTypes: List<Type>
}

Если я использую встроенную модель и не использую другую коллекцию, это может привести к дублированию типа объекта. Например, пользователь A создает тип aa, а пользователь B создает тип bb. Когда они делятся друг с другом, они печатают, это приводит к:

{
    name: UserA,  
    types : [{name: aa}]
    sharedTypes: [{name:bb}]
},
{
    name: UserB,  
    types : [{name: bb}] 
    sharedTypes: [{name:aa}]
}

Что приводит к дублированию, так что я думаю, что это довольно плохой дизайн. Должен ли я использовать другой подход, такой как создание коллекции Type и сохранение referenceId?

Тип коллекции:

{
    id: String
    name: String
}

Что все равно приведет к дублированию, но не к целому документу, я думаю, это будет лучше.

{
    name: UserA,  
    types : ["randomString1"]
    sharedTypes: ["randomString2"]
},
{
    name: UserA,  
    types : ["randomString2"] 
    sharedTypes: ["randomString1"]
}

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

Пользователь коллекции:

{
   id: String
   name: String
}

Тип коллекции:

{
    id: String
    name: String,
    createdBy: String (id of user),
    sharedWith: List<String> (ids of user)
}

Каков наилучший подход между этим3. Я делаю запрос, как, у меня есть одна группа пользователей, поэтому для каждого пользователя я хочу, чтобы созданный тип и тип людей поделились со мной.

Answer 1

В целом решение о встраивании и использовании ссылочного идентификатора сводится к следующему:

1. Вам нужно легко сохранить ссылочную целостность соединенных данных в определенный момент времени, что означает, что вы хотитегарантировать, что состояние соединяемых данных «постоянно связано» с родительскими данными? Тогда встраивание это хорошая идея. Это также хорошая практика в парадигме дизайна «только вставка». Очень часто другие требования, такие как неизменяемость, хеширование / контрольная сумма, безопасность и архивирование, облегчают управление встроенным подходом в долгосрочной перспективе, поскольку управление версиями / createDate значительно упрощается.
2. Вам нужны самые быстрые, самые быстрыеударил масштабируемость? Затем вставьте и убедитесь, что индексы построены соответствующим образом. Индексированный поиск с последующим извлечением богатой формы со сколь угодно сложными встроенными данными - это очень высокопроизводительная операция.
3. (напротив) Хотите, чтобы обновления для присоединяемых данных быстро и немедленно отражались в объединениис родителями? Затем используйте ссылочный идентификатор и функцию $lookup для объединения данных.
4. Растут ли объединенные данные практически без ограничений, как транзакции с учетной записью? Это, вероятно, лучше обрабатывать через ссылочный идентификатор для отдельной коллекции транзакций и объединять с помощью $lookup.