如何在聊天应用程序中构建 Firestore 数据库？

Question

存储聊天消息最简单的方法大概是这样的：

message:
 -message1 {
   "user1"
   "user2"
   "message"
   "date"
  }
 -message2
 -message3

当应用程序变大（大量消息）并且使用.whereEqualTo 完成数据库操作时，以这种方式构建聊天应用程序消息有什么缺点吗？就像数据库遍历所有消息一样？

因为如果这种方法存在问题，例如，我已经看到了这种结构化数据库的方式，它会将消息隔离在不同的聊天室中

chats: {
    -chat1 {
      "lastMessage"
      "timestamp"
      "users": {user1, user2}
    }
    -chat2
    -chat3
  }

messages: {
 -chat1 {
  "message"
  "date"
 }
}

但在本例中，添加新消息需要用户进行 2 次写入操作，一次写入新消息，一次使用新的 lastMessage 和 timestamp 客户端更新 chat 文档，或者创建云函数以添加新消息时，使用新值更新 chat 文档。

那么，第一个选项是否有效，还是我应该使用第二个示例？

Answer 1

您作为第一个选项提供的内容与您在tblMessages 的关系数据库中建模的方式很接近。在 NoSQL 数据库中，这样的直译很少是您的最佳选择，因为它们有非常不同的权衡取舍。例如，您已经注意到需要对两个字段执行查询才能获取两个用户之间的消息。

在 NoSQL 数据库上建模数据时，我通常建议在您的数据库中为您在屏幕上看到的内容建模。因此，如果您的聊天应用程序具有聊天室的概念（即特定人群之间的持续聊天），我也会在您的数据库中对它们进行建模。

在 Cloud Firestore 中，这意味着您将拥有一个顶级集合，其中包含每个聊天室的文档，然后在每个此类文档下都有一个包含该聊天室消息的子集合：

ChatRooms (collection)
  ChatRoom1 (document)
    Messages (collection)
      Message1_1 (document)
      Message1_2 (document)
  ChatRoom2 (document)
    Messages (collection)
      Message2_1 (document)
      Message2_2 (document)

使用此模型，您无需查询即可在聊天室中显示消息，而是可以直接从该聊天室的子集合加载（所有）消息。它还具有对房间进行分区的优点，这意味着写入可以更好地扩展。

我通常建议在房间内建模chat room document IDs after the participants，这样您就可以轻松地根据参与者重建 ID。但是有更多有效的选择。