firebase - Firestore : How to design a Data model to make querying documents that are not exist in an array possible?

Question

我正在尝试找到一种使用 Firestore 正确设计我的数据模型的方法。我正在寻找类似于 Tinder 所做的事情，根据您的位置向您展示您尚未刷卡的人。

所以我最终得到了类似的东西:

User1 有一组“遇见的人”

“尚未遇到用户”/User2 也是具有相同文档模型的用户

它们都属于同一个“用户”集合

我想查询这个User1还没有刷过的所有用户

我知道您不能执行诸如“array_not_contains”或“!=”之类的操作，因为您查询的所有字段都需要编入索引。

所以我想知道，这是否可以对数据进行建模以使其工作，或者唯一的解决方案是删除 Firebase，因为这种查询根本不可能？

一种替代方法是将所有用户之间的所有关系(及其状态)存储在一个集合中。但这也意味着每当用户注册时，我必须创建与用户数量一样多的文档，这真的很丑陋，并制作大量文档。

编辑:

再次感谢您的回答，并为我迟到的回答感到抱歉。

There is no need to create a new database call since you already got all the users from that area in the first place.

不是如果有一个很大的响应集，我将限制为一个数字。 (以下示例中的 5)。
即使我不限制数量，在下一次 db 调用中，我如何知道已添加新人以及如何仅检索那些人。
我不会从用户集合中删除它们，因为它们可以显示给其他用户。

P.S:我忘记了用户集合图片中的 User4。



对于用户 1，先获得 5 个匹配项，删除现有匹配项，显示 User5。
对于 User2，获取 5 个第一个匹配项，删除现有匹配项，显示 User4、User5。
用户选择后，用户将添加到他们的列表中。用户集合保持不变。



对于用户 1，获得 5 首匹配项，删除现有匹配项，不显示任何内容，即使我有用户 6、7。
为了解决这个问题，我启动了第二个查询，获取新的查询，但是，更多的用户使用应用程序，我可能需要做更多的查询来尝试向他显示他所在地区的现有用户。

也许我误解了您命名的“初始列表”，对我而言，它是从包含所有用户(有限制)的数据库中检索的列表对象。

编辑 2:

您可以查看 的答案Alex Mamo 知道如何查询数组中不存在的文档。

让我解释一下我的用例以及为什么我认为这行不通。

我希望能够搜索我旁边的所有用户，为了尝试在 Firebase 中执行此操作，我存储了 Geopoint。 Geopoint 现在不能真正与 Firebase 一起使用，所以我在 Cloud Function 中使用 Geofirestore。
我根据他们的位置存储和更新用户地理点，所以这意味着用户位置 随时间变化 .
我限制了这个函数返回的用户数量。



在我的初始状态下，我检索我旁边的用户(User1)，我得到 3 和 4。
假设我存储上次检查的 userId 以便稍后将其用作查询的游标(用户 4)。

现在我的地理点发生了变化，该区域的用户也发生了变化。
我请求我旁边的下一批用户，并使用我以前的 userId/document 来“startAfter”(更多关于这个
here )，请参见下图，这是行不通的。



如果我使用游标 (User4)，我会取 5，而不是 2，因为在返回列表中，如果我按 Id 排序，2 将在 4 之前。
更糟糕的是，如下所示，如果返回列表中甚至可能没有用户 4，则光标将毫无意义。



我的例子有点简化，没有考虑第一个答案和我的第一次编辑(有限的用户子集，数据设计)中描述的内容。

Answer 1

您的应用程序可能的数据库结构可能是:

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

机制很简单。当您第一次想要向当前(经过身份验证的)用户显示用户配置文件时，您必须创建一个将返回所有用户(在用户区域中)的查询。根据用户决定，需要在 acceptedUsers中任意一个添加对应的uid数组或在 declinedUsers大批。一旦您想显示其他用户，请使用相同的查询，但这一次，您需要进行额外的操作。一旦查询返回用户位置内的用户，将所有这些用户添加到列表中。将来自数据库的列表与您的扩展数组进行比较，并从两个数组中删除所有用户。通过这种方式，您将拥有一个仅包含实际用户没有看到的用户的列表。需要这个额外的步骤来确保用户的 id 不是 存在于这些数组之一中。最后，只需从列表中随机选择一个用户并向用户显示详细信息。就是这样!

One alternative can be to store in a collection all the relationships (with theirs status) between all users. But that also means that whenever a user signup, I have to create as many documents as I have users.....that's really ugly and make a enormous numbers of documents.

这不是一个选项。这意味着您每次用户加入您的应用程序时都需要编写大量数据，这将非常昂贵。由于 Firestore 中的一切都与读写次数有关，因此我认为您应该再考虑一下这种方法。请查看 Firestore usage and limits .

编辑:

让我们考虑具有 10 条记录的初始用户列表。换句话说，该区域内的所有用户都是 10。您说已经看到 7 个用户，这使得列表仅包含剩余的 3 个用户。

So I display the 3, (or I do another request to get some more) and he check the 3.

是的，您应该显示这 3 个用户，然后将它们从初始列表中一一删除。无需创建新的数据库调用，因为您已经获得了 全部 首先是来自该地区的用户。一旦列表保持为空，您应该向用户显示一条消息，说明在该特定区域没有更多用户可以滑动。

When will create another database call?

仅在需要时。这意味着一旦新用户进入该区域，您就创建另一个调用。假设 3 个新用户是新用户，您现在得到 3 个用户的列表并使用相同的算法。

More my user use the app more it’s difficult to show people that he haven’t seen, because his list become bigger.

如果您认为数组的增长将超过文档的容量，那么您应该考虑将用户存储在集合中而不是数组中。所以在这种情况下，问题是文档有限制。因此，当涉及到可以放入文档的数据量时，存在一些限制。根据关于 usage and limits的官方文档:

Maximum size for a document: 1 MiB (1,048,576 bytes)

如您所见，单个文档中的数据总量限制为 1 MiB。当我们谈论存储文本 (uid) 时，您可以存储很多东西，但随着数组变大，请注意此限制。

但是如果你保持在这个限制内，我个人认为你会这样做，你就没有什么可担心的。

编辑 2:

Not If have a large response set, I will limit to a number. (5 in the example below). And even If I don't limit the number, in the next db call, how I can know that new peoples has been added and how to retrieve only those. I will not remove them from Users Collection has they can be show to others users.

如果您有大量数据(单个区域中有许多用户)，是的，限制结果是个好主意，但更好的主意是以更小的块加载数据。简而言之，获取5个用户，一个一个删除，直到列表有0个用户，加载其他5个用户，依此类推。这可以使用我在以下帖子中的回答来完成:

Is there a way to paginate queries by combining query cursors using FirestoreRecyclerAdapter?

初始列表是您第一次查询数据库时获得的列表。在这种情况下，初始列表将包含 5 个用户。