Схема на mongodb для сокращения вызовов API с двумя коллекциями

Question

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

1. Мой клиент ищет фотографии по определенным критериям. Предположим, он получил 50 фотографий из поиска (т. Е. Один запрос mongodb). Каждое изображение связано с одним пользователем. Я также хочу, чтобы имя пользователя отображалось. Я предполагаю, что нет никакого способа сделать один результат поиска мудрую в коллекции пользователей, возвращая имена каждого пользователя для каждого изображения, то есть мне нужно будет выполнить 50 поисков. Это означает, что я мог бы избежать этой дополнительной загрузки производительности путем дублирования данных (рядом с user_id, а также имя пользователя) в моей коллекции изображений?

2. Тот же вопрос, наоборот. Если мой клиент ищет пользователей и говорит, что 50 пользователей возвращаются из поиска по одному запросу. Если я хочу, чтобы последнее связанное изображение + заголовок также отображалось рядом с пользовательскими данными, я снова должен добавить это в коллекцию пользователей, иначе я предполагаю, что мне нужно сделать 50 запросов, чтобы вернуть данные изображения?

Answer 1

Допустим, схема для вашей коллекции картины как таковой:

Изображение документа

{ 
    _id: Objectid(123), 
    url: 'img1.jpg', 
    title: 'img_one', 
    userId: Objectid(342) 
} 

1) Ваш запрос изображение будет возвращать документы, которые выглядят как выше. Вам не нужно делать 50 звонков, чтобы связать пользователя с изображениями. Вы можете просто сделать другого запроса к Users Collection с использованием идентификаторов пользователей, взятые из изображения документов, как, например:

db.users.find({_id: {$in[userid_1,user_id2,userid_3,...,userid_n]}}) 

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

Альтернативно

Вы могли бы разработать схему, как, например:

Изображение документа

{ 
    _id: Objectid(123), 
    url: 'img1.jpg', 
    title: 'img_one', 
    userId: Objectid(342), 
    user_name:"user associated" 
} 

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

2) Вы можете создать свой Коллекцию пользователя, как, например:

Документ пользователя

{ 
    _id: Objectid(342), 
    name: "Steve jobs", 
    last_assoc_img: { 
      img_id: Object(342) 
      url: 'img_one', 
      title: 'last image title 
    } 
} 

Вы можете использовать те же принципы, как уже упоминалось выше.

Answer 2

Если предположить, что у вас есть userid, связанный с каждым user и вы также хранения, что id в picture документе, то ваш user < =>picture является слабо связаны отношениями.

Чтобы не было необходимости совершать 50 отдельных вызовов, вы можете использовать $in operator, учитывая, что вы можете вытащить те id и положить их в список для запуска второго запроса. Ваш запрос будет в основном на английском языке: «Посмотрите на сборник, если он находится в списке id, отдайте его мне».

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