Ios Firebase的消息传递应用程序数据库结构

我正在使用Firebase构建一个应用程序。该应用程序的一个功能是聊天功能，用户可以通过聊天功能向其他用户发送消息——没有什么特别的，只是基于文本的一对一用户消息。所有在线教程都描述了如何实现匿名身份验证，例如匿名身份验证或利用匿名身份验证，因此许多原则似乎并不适用。我正在让用户在使用此功能之前进行身份验证

看来，我掌握的两件主要事情是修改应用程序JSON数据库结构中特定路径（添加、编辑、删除、变更单）的内容，并在客户端观察这些更改的发生。我可以很容易地将每条消息放在同一个子项中，并侦听消息子项的任何更改，然后通过查找与当前用户ID关联的消息，将每条消息解析为客户端对话。然而，这种方法似乎效率低下，因为在我看来，我必须过滤掉大量多余的消息

---

描述观察结构应该如何工作的一般流程、我需要在每条消息中包含什么以及如何有效地将对话分类将非常有帮助。

大多数聊天应用程序都使用聊天室的概念，可以是直接对话的1:1聊天室，也可以是用户组之间的命名聊天室

将每个房间建模为数据库中的一个节点，在房间id下（仅）显示该房间的消息：

chatrooms
  roomdid1:
    msg1: { from: ..., text: ..., timestamp: ... }
    msg2: { from: ..., text: ..., timestamp: ... }
    msg3: { from: ..., text: ..., timestamp: ... }
  roomdid2:
    msg4: { from: ..., text: ..., timestamp: ... }
    msg5: { from: ..., text: ..., timestamp: ... }
    msg6: { from: ..., text: ..., timestamp: ... }

要加载某个房间的消息，只需收听该房间，例如

/chattrooms/roomid1

---

有关基于房间中用户的房间命名约定的想法，请参见。

感谢您的指导，这非常有帮助。我唯一的想法是，手动解析所有聊天室并根据聊天室ID查看用户是否在聊天室中可能会非常慢（当他们开始填充数据时，下载所有聊天室可能会很慢）。创建另一个只包含聊天室ID的节点并搜索它是否是一种好做法？这确实是一个坏主意。您通常会通过UID获得每个用户的房间列表。所以：

/userrooms/$uid/roomid1:true

，

/userrooms/$uid/roomid2:true

，等等