最简单的聊天消息存储方式大概是这样的:
message:
-message1 {
"user1"
"user2"
"message"
"date"
}
-message2
-message3
当应用程序变大时(很多消息),并且数据库操作是通过 .whereEqualTo
完成的,以这种方式构建聊天应用程序消息有什么缺点吗?就像数据库遍历所有消息一样?
因为如果这种方法存在问题,例如我已经看到这种构建数据库的方式,它会在不同的聊天室中隔离消息
chats: {
-chat1 {
"lastMessage"
"timestamp"
"users": {user1, user2}
}
-chat2
-chat3
}
messages: {
-chat1 {
"message"
"date"
}
}
但在此示例中,添加新消息需要用户进行 2 次写入操作,一次写入新消息,一次使用新的 lastMessage
和 更新
客户端,或者创建一个云函数来在添加新消息时用新值更新 chat
文档timestampchat
文档。
那么,第一个选项是否有效,或者我应该使用类似于第二个示例的方法?
最佳答案
您作为第一个选项提供的内容与您在 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。但是对此有更多有效的选择。
关于android - 如何在聊天应用程序中构建 Firestore 数据库?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/54008366/