Firestore: Как спроектировать модель данных, чтобы сделать возможным запрос документов, которых нет в массиве?

Возможная структура базы данных для вашего приложения может быть:

Firestore-root
    |
    --- users (collection)
         |
         --- uid (document)
              |
              --- acceptedUsers: ["uidOne", "uidTwo"]
              |
              --- declinedUsers: ["uidThree", "uidFour"]
              |
              --- //Other user properties

Механизм прост. Когда вы впервые захотите показать профиль пользователя текущему (прошедшему проверку подлинности) пользователю, вы должны создать запрос, который будет возвращать всех пользователей (в пользовательской области). В соответствии с решением пользователя вам необходимо добавить соответствующий uid в массив acceptedUsers или в массив declinedUsers. Если вы хотите показать других пользователей, используйте тот же запрос, но на этот раз вам нужно будет выполнить дополнительную операцию. Как только запрос вернет пользователей в пределах их местоположения, добавьте всех этих пользователей в список. Сравните список, поступающий из базы данных, с существующими массивами и удалите всех пользователей из обоих массивов. Таким образом, у вас будет список, содержащий только пользователей, которых фактический пользователь не видел. Этот дополнительный шаг необходим для того, чтобы убедиться, что идентификатор пользователя не существует в одном из этих массивов. В конце просто выберите случайного пользователя из списка и покажите детали пользователю. Вот и все!

Одной из альтернатив может быть сохранение в коллекции всех взаимосвязей (с их статусом) между всеми пользователями. Но это также означает, что всякий раз, когда пользователь регистрируется, мне приходится создавать столько документов, сколько у меня пользователей ... это действительно ужасно и делать огромное количество документов.

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

Редактировать:

Давайте рассмотрим первоначальный список пользователей, который имеет 10 записей. Другими словами, все пользователи в этой области - 10. Вы говорите, что 7 пользователей уже видели, то есть список содержит только 3 оставшихся пользователя.

Итак, я отображаю 3 (или делаю еще один запрос, чтобы получить больше), и он проверяет 3.

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

Когда будет создан еще один вызов базы данных?

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

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

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

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

Как вы можете видите, вы ограничены 1 МБ данных в одном документе. Когда мы говорим о хранении текста (uids), вы можете хранить довольно много, но по мере увеличения массива будьте осторожны с этим ограничением.

Но если вы будете оставаться в этих пределах, что я лично считаю, вам не о чем беспокоиться.

Edit2:

Not Если задан большой ответ, я ограничусь числом. (5 в примере ниже). И даже если я не ограничу число, в следующем вызове БД, как я могу узнать, что новые люди были добавлены и как получить только те. Я не буду удалять их из Коллекции пользователей, если они могут быть показаны другим пользователям.

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

• Есть ли способ разбивать запросы на страницы, комбинируя курсоры запросов с помощью FirestoreRecyclerAdapter?

Начальный список - это список, который вы получаете при первом запросе к базе данных. В этом случае первоначальный список будет содержать 5 пользователей.