基本的firebase數據庫結構設計決策

Question

情況：

在應用程序中，我們有多達1000所學校。每所學校都有學生和學生上課並參加活動（等等）。我們需要快速且經常地爲每個學生每個學校的日期查詢課程。我們有兩種設計，想知道最佳的處理方式。

1 - 設計專用校節點

2 - 設計，沒有專用校節點

的兩種設計實例

PRO設計1
- 登錄後向學校用戶提供root權限。野應需要在學生證
查詢 - 沒有必要提及學生證到處
- 無需節點的每個學校減輕和每個學校活動
- 上一級學校
...

PRO設計2規則
- 更扁平化的數據，作爲互聯網

Answer 1

對於大多數的NoSQL數據庫結構上廣爲告知，壓扁denormalising數據是最好的方法。 Firebase也是如此。

當您彙整數據，你會得到以下優點： -

1. 你大多隻下載所需的最低量。這導致了效率和成本效益。
2. 您的下載速度要快得多 - 特別是與SQL連接查詢類似。

話雖如此，在您的具體情況下，我認爲這取決於school對登錄用戶的影響程度。

假設school只是一個學生的屬性，並沒有其他用途，那麼第二個數據庫就是要走的路。例如，如果一個學生可以得到的書獨立於她所去的學校，那麼第二個數據庫風格更適合。

但是，如果school類別的學生成爲定義它們與數據庫交互的組，那麼第一個數據庫結構就是要走的路。一個例子就是，一個學生只有在她去的學校有書時才能得到一本書。

無論您的決定如何，我想讚揚您的事實，即您的數據庫在您的結構中已經變得非常好！我個人的建議是使用更方便的編碼，閱讀和維護。