Question

我的应用程序的基本流程是用户向他们的朋友发送帖子，并且朋友可以发布对该帖子的回复，并且发送初始帖子的每个人都可以看到每个人的回复。

我有两种选择：

1)
users
  9308490384
     postsInitiated
         029309jf: true
     InitiationsInvitedTo
         lsfjijl39j390jf: true
         lkajls;dkfj3ijl3f: true
initiations: 
   029309jf
      timestamp: 293084093
      picURL: picture.com
      replies:
           abc123: true
           edf234: true
   lsfjijl39j390jf
       etc..
replies: 
   abc123         
      picURL: picture.com
      posterUID: lsjdflkjk

2）

users
  9308490384
     postsInitiated
         029309jf: true
     InitiationsInvitedTo
         lsfjijl39j390jf: true
         lkajls;dkfj3ijl3f: true
initiations: 
   029309jf
      timestamp: 293084093
      picURL: picture.com
      replies:
         abc123         
             picURL: picture.com
             posterUID: lsjdflkjk

两者之间的区别在“回复”下的启动下。第一个选项有一个回复列表，如

abc123: true

然后我会使用abc123键搜索回复位以找到picURL / posterUID。

第二个选项只是在Initiation的回复位中列出回复数据。

我看到很多聊天应用程序都有一个用户消息节点，然后是“所有消息”数组，你使用来自用户消息节点的消息的UIDS来搜索所有消息节点。

在这种情况下，仅在“启动”下列出回复信息是否存在任何潜在问题？通过指向“回复”节点，我肯定可以更加扁平化，但这似乎是不必要的。我没有看到需要压扁那么多，但几乎在任何地方我都认为它会尽可能地压平你的数据。

Answer 1

方法1的优点是您只需要在一个地方写入数据。因此，它简化了编写数据的代码。它还将数据复制量减少到只有密钥。

方法2的优点是您只需要从树中的一个位置加载数据。因此，它简化了读取数据的代码。它也有很小的性能优势，但这不应该是选择该模型的原因。

没有特定的最佳解决方案（说实话：几乎没有）。这一切都取决于您的应用程序及其用例。由于您在构建应用程序时可能会发现用例（并且当您的用户开始使用它时），因此任何一种方法都可能足以开始使用。

Firebase-数据库结构效率与平坦度

1 个答案: