Я читал много SO-сообщений о конкретных ситуациях запроса и столкнулся с препятствиями на моем пути, пытаясь определить наилучший подход, не выходя за рамки запросов на чтение.
У меня есть приложение, в которомПользователь может следить за несколькими исполнителями, и на главной странице он должен отображать предстоящие представления, отсортированные по дате.Я хочу ограничить количество чтений до 15, но при настройке моей структуры я не могу ограничить общее чтение, а просто чтение для конкретного исполнителя.Позвольте мне объяснить:
Для конкретного пользователя я сохраняю всех артистов, за которыми следует пользователь, в массив:
user: {
userUsername: 'jlewallen18',
userArtistUIDs: [1,4,8,9]
}
Чтобы установить соединение с отправкой от исполнителя, за которым следует пользователь,Я добавляю artistUID
к представлению:
submission: {
submissionArtistUID: 4,
submissionTitle: 'New Album'
submissionReleaseDate: 1550707200
}
Теперь способ найти то, что мне нужно отобразить на домашней странице для конкретного пользователя, - это просмотреть все идентификаторы исполнителей и подписчиков пользователей и выполнить запросдля представления с этим идентификатором.Затем я могу подписаться на эту наблюдаемую запись, используя combineLatest
из rxjs
и получить свои результаты.
this.submission$ = user.userArtistUIDs.map((id) => {
return this.db.collection$('submissions', ref => ref
.where('submissionArtistUID', '==', id));
});
Это прекрасно работает, но не подходит для моей квоты на чтение, поскольку запрашивает каждый выпуск изкаждый артист, за которым я следую.Поэтому, если я буду следить за 300 исполнителями, у каждого из которых будет 3 выпуска, мне нужно будет отправить в приложение 900 операций чтения, и мне придется отсортировать и нарезать окончательный массив, чтобы сократить его до 15 на стороне клиента.
Этоэто то, что я ищу:
С моим списком ArtistID -> запрос для заявок, которые содержат ArtistID в моем массиве -> сортировка по возрастанию -> ограничение до 15.
Таким образом, мой счетчик чтения будет только 15. Я знаю, что для NoSQL не существует единственной хитрости, но я изо всех сил пытаюсь найти оптимальный метод, поскольку в моем приложении будет больше операций чтения, чем записей.