用户对用户（和组）聊天应用程序的Firebase数据库布局是否正确？

Question

我试图了解使用Firebase数据库来存储和检索用户对用户对话（基于web）的最佳数据库结构。

我当前的计划是为每个聊天提供自己的ID，该ID将通过组合两个聊天参与者的唯一Firebase ID（如userid1_userid2)创建，例如:FQ5D0JWLQDCQLRYZEVBXKRP72BB2_GSIBXEMI4JONWHRZAQ528KJKDBM8该聊天ID将存储在数据库中，并包含两个参与者之间发送的消息。

布局示例：

MYAPP
    |_______conversations
    |                   |_____UserID1_UserID2
    |                   |                   |
    |                   |                   |__OshwYF72Jhd9bUw56W7d
    |                   |                   |                     |__name:"Jane"
    |                   |                   |                     |__text:"Hello!"
    |                   |                   |
    |                   |                   |__KbHy4293dYgVtT9pdoW
    |                   |                   |__PS8tgw53SnO892Jhweh
    |                   |                   |__Qufi83bdyg037D7RBif
    |                   |                   |__Gicuwy8r23ndoijdakr
    |                   |
    |                   |_____UserID5_UserID16
    |                   |_____UserID8_UserID7
    |                   |_____UserID3_UserID8
    |
    |_______users

每当用户登录应用程序，他们就会看到他们的联系人列表。当他们选择一个聊天对象时，我会使用一些Javascript将他们的朋友的Firebase ID和他们选择的朋友的Firebase ID组合起来生成聊天ID。然后，这个聊天ID可以在数据库中创建（如果这是他们第一次聊天），或者用来从数据库加载他们以前交换过的消息（如果他们以前聊天过）。

我的问题是，这是正确的使用方法吗？如果我使用这种方法，我会遇到什么问题？例如，如果我将来尝试实施小组对话（与2人以上），我会有问题吗？

Answer 1

在创建NoSQL数据库时，我想指出的最重要的“规则”之一是，您必须

在视图之后对数据进行结构化。

这意味着数据必须以这样的方式进行结构化，当您想要在您的视图（可能是您的html页面）上显示它时，只需进行一次读取。

您会注意到，通过这种方式，您实际上可以轻松地为每次聊天添加更多的参与者。请注意，这不是您唯一的节点。您必须创建其他节点，如用户（存储用户详细信息）和消息（存储每个聊天的消息）等。为了帮助您实现这些，我建议您查看David East的Firebase数据库，以供SQL开发人员使用。