如何对 Firestore 数据建模？答案

【问题标题】：How to Model Firestore Data?如何对 Firestore 数据建模？
【发布时间】：2020-10-19 21:43:04
【问题描述】：

我是 Firestore 的新手，正在尝试为我的应用开发数据模型。

背景：我有一种约会类型的应用程序，用户可以通过 3 种主要方式相互交流。喜欢、拒绝和评论用户个人资料。用户喜欢和 cmets 是私人的。换句话说，只有我可以看到谁喜欢或评论了我的个人资料（它不像社交媒体，每个人都可以看到谁喜欢了一个帖子）。我需要能够查询用户以了解谁取消了他们的个人资料，因此我不会再次向这些用户显示。我还需要知道谁喜欢/评论了用户个人资料，这样我就可以查询哪些用户互相喜欢/评论了（他们已经匹配）

用户可以喜欢许多个人资料，反之亦然
用户可以关闭/跳过许多个人资料，反之亦然
用户可以评论许多个人资料，反之亦然

我相信这意味着我需要 likedUsers、dismissedUsers 和 commentedUsers 的根集合

问题： 对于被解雇的用户，我想我会将每个用户存储为dismissedUsers 根集合的文档，并将他们跳过的每个用户存储为一个字段/值对，就像这样......

dismissedUsers/User/user1、user2、user3 等

以上将创建我想要的多对多关系，其中被解雇的用户可以有很多用户，而用户可以有很多被解雇的用户。但是，我不相信它会随着用户文档变得太大而具有可扩展性。

问题：我如何创建这种多对多关系，其中dismissedUsers 可以有很多用户，而用户可以有很多dismissedUsers，以便它具有可扩展性且成本最低？并查询？

【问题讨论】：

将文档添加到文档 D 下的子集合不会使文档 D 的大小变大。每个文档都是完全独立的，无论它在哪里组织。
@DougStevenson 好的，所以我应该在用户文档中添加一个子集合，用于 likeUsers、dismissedUsers、commentedUsers？明白了，但我读到，当这样做时，数据的范围仅限于该特定用户（防止跨父文档查询）？不是这样吗？
您可能想了解集合组查询，以跨具有不同父文档的子集合进行查询。
这个问题的问题是它太模糊了，我们没有足够的信息来评估这个问题。例如用户文档会变得太大这是什么意思？太大了怎么办？您可以在 /users/uid 文档中存储数以万计具有该格式的文档，这将是少量数据。此外，为什么还要首先将其存储在那里？为什么没有单独的集合来存储用户被解雇的用户？然后它与用户文档完全分开。 我如何创建这种多对多关系 - 拥有用户和解雇用户集合。
@Jay 假设层次结构如下：users/user1/dismissedUsers/user2,user3,user4等。我的问题是我如何建模和执行不等式查询来加载所有用户（对于 user1），除了dismissedUsers 子集合中的用户？

标签： ios swift firebase firebase-realtime-database google-cloud-firestore

【解决方案1】：

您不需要对其他用户个人资料点赞、拒绝或评论的用户集合。您可以拥有一个存储所有用户的用户集合。在每个用户文档中，您可以拥有三个用户 ID 数组，这些用户 id 喜欢、评论和/或取消了用户配置文件。只需确保 users 集合中文档的文档 ID 与相应用户的用户 ID 匹配即可。

【讨论】：

我认为在用户文档上为喜欢、拒绝、评论的用户创建数组是不可扩展的

【解决方案2】：

首先，我会问自己为什么要使用 Firestore，作为文档数据库，而不是选择关系数据库。我个人喜欢 Firestore 并强烈推荐它。我们选择文档数据库是因为它在许多方面都更快、更容易使用。在其他方面，这是一个缺点，因为您的查询能力非常有限。在我看来，您的大脑正在努力实现关系数据库。

这是一种解决方案

首先，我会尽量避免将用户数据存储在多个位置以避免异常（当然是正确的）。我将拥有一组用户，在其中存储具有唯一 ID 的所有用户数据（最好使用 Firestore 分配的用户数据，这样我就不会发生冲突）。在每个用户文档中，我将链接一个子集合，用于解雇、喜欢、被其他人解雇、被其他人喜欢等。我会记录他们已经解雇、喜欢、被解雇的所有用户（只是用户 ID） by、被喜欢等。这样我可以查找该用户喜欢或不喜欢谁的所有数据，并相应地向该用户显示我想要的任何内容。

缺点

您必须为每个赞、关闭等写入两次。使用批量写入同时更新点赞和点赞数据。

【讨论】：

好的，为用户文档创建子集合是有意义的。但是，我还有查询父文档的权限吗？例如，User1 是否喜欢 User30？
是的，因为您可以检查 User1 的“喜欢”集合以查看 User30 的 userId 是否存在。路径类似于 firestore.collection('users').doc(User1's user ID).collection('liked')，然后查询该集合以查找 User30。如果您愿意，第三个（不相关的）用户仍然可以访问此数据，但您希望通过应用程序的声音将其保密，因此请相应地设置安全规则。
为每个用户提供自己的收藏集的好处之一是您可以设置严格的安全规则，这样精明的用户就看不到他们不应该看到的信息。
还有一个问题，假设我有以下层次结构：users/user1/dismissedUsers/user2、user3 等 - 我如何使用不等式查询来加载所有用户（对于 user1）而不是 dislikedUsers 子- 收藏？
这是像 firestore 这样的文档数据库的缺点之一。我不知道用 Firestore 查询来做到这一点您可能想发布另一个问题来询问这个问题，看看其他人是否有任何想法。否则，您可能需要一个具有更多查询能力的关系数据库。