如何在聊天应用程序中构建Firestore数据库? [英] How to structure Firestore database in chat app?

问题描述

最简单的聊天消息存储方式可能是:

The simplest way of storing chat messages is probably this:

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

当应用程序增大(大量消息)并且使用.whereEqualTo完成数据库操作时，以这种方式构造聊天应用程序消息是否有任何缺点?就像数据库遍历所有消息一样?

When the app grows in size (a lot of messages), and operations on database are done with .whereEqualTo are there any disadvantages of structuring chat app messages this way? Like with database iterating through all messages ?

因为这种方法存在问题，例如，我见过这种结构化数据库的方法，该方法可以将消息隔离在不同的聊天室中

Because if there are problems with this approach, i've seen for example this way of structuring database, that would segregate messages in different chat rooms

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

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

但是在此示例中，添加新消息将需要用户执行2次写入操作，一项写入新消息，以及一项使用新的lastMessage和timestamp客户端更新chat文档，或创建云函数以执行以下操作:添加新消息后，用新值更新chat文档.

But in this example, adding new message would require user to make 2 write operations, one writing new message and one updating chat document with new lastMessage and timestamp client-side, or creating a cloud function to update chat document with new values, when new message is added.

那么，第一个选项是否有效，还是我应该选择类似第二个示例的内容?

So, is the first option valid, or should I go with something like the second example?

推荐答案

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

What you've offered as the first option is close to how you'd model this in a relation database in a tblMessages. Such a literal translation is seldom your best option in NoSQL databases, since they have very different trade-offs. For example, you've already noticed that you need to perform a query on two fields to get the messages between two users.

在NoSQL数据库上建模数据时，通常建议您在数据库中根据屏幕上看到的内容进行建模.因此，如果您的聊天应用程序具有聊天室的概念(即特定人群之间的持续聊天)，我也将在您的数据库中对其进行建模.

When modeling data on a NoSQL database, I usually recommend modeling in your database for what you see on your screen. So if your chat app has the concept of chat rooms (i.e. persistent chats between specific groups of people), I'd model those in your database too.

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

In Cloud Firestore that means that you'd have a top-level collection with a document for each chat room, and then a subcollection under each such document with the messages for that chat room:

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

使用此模型，您无需查询即可在聊天室中显示消息，而可以直接从该房间的子集合中加载(所有)消息.它还具有划分房间的优势，这意味着写入可以更好地扩展.

With this model you don't need to query to show the messages in a chat room, but can instead just load (all) the messages straight from the subcollection for that room. It also has the advantage that you partition the rooms, meaning that writes can scale much better.

我通常建议为参与者建模聊天室文档ID./a>，以便您可以根据参加者轻松地重建ID.但是，对此还有更多有效的选择.

I typically recommend modeling the chat room document IDs after the participants in the room, so that you can easily reconstruct the ID based on the participants. But there are more valid options for this.

这篇关于如何在聊天应用程序中构建Firestore数据库?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！