哪个更适合Firebase中聊天应用程序的数据模式

这是使用Firebase的群聊应用程序。我有几个数据模式选项，我不知道什么会更好的性能和更少的数据使用情况。哪个更适合Firebase中聊天应用程序的数据模式

假设有10个房间。这间客房已经制成。

每个房间的id是[A，B，C，d，E，F，G，H，I，J]

选项1

/用户
- /$ UID /接合
  - ROOM1 {roomId：A}
/间
- ROOM1 {roomId：A，用户：[...]}
/消息
- ROOM1 {roomId： A，讯息：[...]

选项2

/用户
- /$ UID /加入
  - 房间1 {roomId：A，lastChecked，joinedAt ...}
/间
- ROOM1 {roomId：A，用户：[]，消息：[]}

哪个更好？我第一次计划使用选项1.为了减少数据使用量，我想单独处理房间的简要信息和消息。但是，开发的过程中，我实现了火力的数据库是由特定的键处理...

例如，当用户访问一个房间，

更新他/她加入了房间信息/users/$uid/joined，需要。
更新房间的参与用户在/rooms/$roomKey/users，roomKey需要，我必须查询使用房间的ID（A）
它接入房间后，在/rooms/$key/messages获取消息和它的关键是不同的上面$roomKey。

上面是选项1的情况，如果我使用选项2，我不需要在不同路径中再次获取消息。但为什么我问这个问题的原因，然后如何渲染“加入房间列表”屏幕？每个房间应该有一个简短的信息，如标题，用户数量，未读消息的数量。如果我将消息放入/rooms，则会一起查询消息。对？

我认为这些消息是最大的数据大小。我怎样才能使这个数据结构？

来源

2017-08-27 Juntae

我想借此在2选项，因为它更容易管理的安全规则，但1.选择是没有错的或坏的^^

如果你想保持数据的小和唐的大小不想浪费任何东西，你可以选择这样的结构：

- users 
    - $uid .... 

- rooms 
    - $roomid 
    - info 
     - title 
     - description 
     - .... 
    - messages 
     - $messageid 
     - .... 
    - users

现在你只加载当前需要的孩子。但是您的安全规则仍然紧凑。

来源

2017-08-27 08:40:18 janik174

哪个更适合Firebase中聊天应用程序的数据模式

回答

相关问题