Javascript 社交媒体应用程序中用户交互的Firestore结构 介绍

我有一个典型的“交互”屏幕，其中显示了一个无限列表，其中有在我的一篇帖子中喜欢/评论的用户，也有最近发送新邮件的用户。此屏幕位于带有“标记图标”的选项卡导航器中（显示新交互的数量）

此外，我还有另一个名为“Messages”的堆栈屏幕，其中显示了新聊天的数量和聊天列表

为了获得“新交互”和“新聊天”的数量，我想模拟一个堆栈（在我的Firestore上推送数据和弹出数据）

数据库结构 为了处理此用例，我曾想过将我的数据库结构如下：

/ (root)
|
--> /interactions (collection)
|    |--> /userId (document)
|         |--> pendingPostsInteractionsCount (number) <-------- Always increase. Reset to 0 when the user open the "notifications" screen.
|         |--> pendingChatsCount (number) <-------- Always increase. Decrease when the user open an unread chat.
|         |--> /posts (collection)
|         |     |--> /postId (document)
|         |           |--> /likes (collection)
|         |           |     |--> otherUserId (document)
|         |           |          |--> { date: Date }
|         |           |     ...
|         |           |
|         |           |--> /comments (collection)
|         |                 |--> otherUserId (document)
|         |                      |--> { comment: String, date: Date }
|         |                 ...
|         |              
|         |--> /chats // There are no "groups" in my app
|               |--> otherUserId (document)
|                     |--> messages (collection)
|                          |--> messageId (document)
|                                |--> { text: String, date: Date }
|                          ...
|
|--> /posts (collection)
|    |--> /userId (document)
|          |--> /userPosts (collection)
|               |--> postId (document)
|                     |--> { ...postData }
|               ...
|          ...
|           
|--> /users (collection)
      |--> userId (document)
            |--> { ...userData }
      ...

/（根目录）
|
-->/互动（收集）
||-->/userId（文档）
||-->PendingPostsInteractionScont（编号）PendingChatScont（编号）/posts（收集）
|| |-->/posted（文件）
|||-->/likes（系列）
|| | |-->其他用户ID（文档）
|| | |-->{date:date}
|         |           |     ...
|         |           |
|| |-->/comments（集合）
|| |-->其他用户ID（文档）
|| |-->{注释：字符串，日期：日期}
|         |                 ...
|         |              
||-->/chats//我的应用程序中没有“组”
||-->其他用户ID（文档）
||-->消息（集合）
||-->消息ID（文档）
||-->{text:String，date:date}
|                          ...
|
|-->/员额（收集）
||-->/userId（文档）
||-->/userPosts（集合）
||-->已过账（文件）
||-->{…postData}
|               ...
|          ...
|           
|-->/用户（集合）
|-->用户ID（文档）
|-->{…用户数据}
...

问题

由于我需要显示一个标记图标，我将不得不监听数据库更改。。。我想听听/interactions/{userId}文档中的更改，然后，在我的客户端，如果PendingChatScont或PendingPostSinterActionScont已更改，则更新标记图标

当用户导航到“喜欢”或“评论”屏幕时，他/她将分别看到用户指定帖子的喜欢或评论列表

这两种情况能用这种结构正确处理吗？或者将注释和likes集合放在/posts/{userId}/userPosts/{postId}/（也作为子集合）中更好吗

Firestore能否同时执行“多个集合查询”？因此，在我的“交互”屏幕中，我可以从按日期排序的不同集合中获取所需数据

例如，如果我想在交互屏幕中实现pull-to-refresh，并将其与onSnapshot侦听器相结合，那么这种结构是讨论分页的一个好选择吗

总之，基本上我想知道的是，对于我所评论的操作来说，这是否是一个简单而好的结构

Pd：在我的例子中，我决定以这种方式构造交互，以便不必在数据库中复制数据，因此，当我进入帖子的likes屏幕时，我还可以重用集合“interactions/{userId}/posts/{postId/likes/”来读取数据

如果有人对Firestore和NoSQL数据库有总体经验，我将非常感谢您的反馈或建议

---

谢谢。

将此作为社区维基发布，因为@DougStevenson对此发表了评论，并回答了以下问题：

---

如果你可以通过查询来满足你的应用程序的需求，那么是的，这就足够了。 这才是真正重要的。如果它不能满足查询，那么您需要后退一步，仔细定义查询，然后构建数据以满足它们

---

NoSQL数据建模通常遵循您需要的查询，因此请先定义这些查询。

如果您可以进行查询以满足应用程序的要求，那么是的，这就足够了。这才是真正重要的。如果它不能满足查询，那么您需要后退一步，仔细定义查询，然后构建数据以满足它们。NoSQL数据建模通常遵循您需要的查询，因此请先定义这些查询。好的，非常感谢，我将遵循您的建议。我担心这是一个有点疯狂的结构或风格，甚至在设计它们时考虑了要进行的咨询……但是，如果有人感兴趣，我不会删除这个问题这种结构或者说可以在将来帮助他们。