哪個更適合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中聊天應用程序的數據模式

回答

相關問題