Firebase Firestore Структура для получения невидимых трендовых постов - Social

Question

Это текущая структура выборки

Posts(Collection)
    - post1Id : {
          viewCount : 100,
          likes     : 45,
          points    : 190,
          title     : "Title",
          postType  : image/video
          url       : FileUrl,
          createdOn : Timestamp,
          createdBy : user20Id,
          userName  : name,
          profilePic: url
      }
Users(Collection)
    - user1Id(Document):{
          postsCount : 10,
          userName  : name,
          profilePic : url
      }
        viewed(Collection)
            - post1Id(Document):{
                  viewedTime : ""
              }

    - user2Id(Document)

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

Каковы возможные оптимальные решения (например, изменение структуры, облачные функции, множественные запросы со стороны клиента)?

Answer 1

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

Users(Collection) -> userId(Document) -> viewed(Collection)

В качестве документов - все сообщения, которые просмотрел пользователь, и вы хотите получить все сообщения, которые пользователь не видел. Поскольку в Firestore нет ни оператора != (не равного), ни функции arrayNotContains(), единственный вариант, который у вас есть, - это создать дополнительный вызов базы данных для каждого сообщения, которое вы хотите отобразить, и проверить, является ли это конкретное сообщение уже видел или нет.

Чтобы достичь этого, сначала вам нужно добавить еще одно свойство под вашим объектом записи с именем postId, которое будет содержать в качестве String фактический идентификатор записи. Теперь каждый раз, когда вы хотите отобразить новые сообщения, вы должны проверять, существует ли идентификатор сообщения в коллекции viewed или нет. Если его не существует, отобразите этот пост в нужном вам представлении, в противном случае - нет. Вот и все.

---

Редактировать: По вашим комментариям:

Итак, чтобы появилось первое сообщение, ему нужны два вызова Сервера.

Да, чтобы появилось первое сообщение, нужны два вызова базы данных: один для получения сообщения, а второй - для того, чтобы увидеть, было ли оно увидено или нет.

большое количество обращений к серверу для получения первого сообщения.

Нет, только два звонка, как описано выше.

Я вижу это неправильно

Нет, так работает база данных NoSQL.

или другого эффективного пути нет?

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

Но , если сообщение могут просматривать миллионы пользователей, хранение миллионов идентификаторов в массиве не является хорошим вариантом, поскольку проблема в этом случае заключается в том, что документы имеют ограничения . Таким образом, существуют некоторые ограничения в отношении объема данных, которые вы можете поместить в документ. Согласно официальной документации относительно использования и ограничений :

Максимальный размер документа: 1 МБ (1 048 576 байт)

Как вы можете видеть, вы ограничены суммой в 1 МБ данных в одном документе. Таким образом, вы не можете хранить практически все в документе.