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

Question

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

我有 2 个选择:

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。

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

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

这种情况下只在Initiations下列出回复信息会不会有潜在的问题？我绝对可以通过指向“回复”节点来进一步展平它，但这似乎没有必要。我认为没有必要扁平化那么多，但我看到的几乎所有地方都建议您尽可能扁平化数据。

Answer 1

方法 1 的优点是您只需在一个地方写入数据。因此它简化了写入数据的代码。它还减少了仅键的数据重复量。

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

没有具体的最佳解决方案(老实说:几乎没有)。这完全取决于您的应用程序及其用例。由于您可能会在构建应用程序时(以及当您的用户开始使用它时)发现用例，因此这两种方法都可能足以开始使用。