Firestore 子集合與數組

Question

首先，我知道 Firestore 是如何工作的，並且花了很多時間來評估不同的方法以獲得良好的結構。 我仍然在考慮以下情況：

有一個已知食譜的數據庫。 用戶可以添加食譜，但必須確認它們是真實的食譜，而不僅僅是一些變體。 因此每個用戶都可以從用戶生成的食譜列表中選擇收據來聲明，他們知道如何烹飪它們（或添加新的）。

現在我希望用戶與其他人分享他們的收據列表，但我不確定如何使用 Firestore 最好地完成這一點。 訣竅是，我想一次顯示所有食譜，並且不想對它們進行分頁。

我目前正在評估兩種可能性：

子集

每當用戶共享他的列表時，查看所述列表的用戶將不得不加載整個食譜列表，這可能導致大量文檔讀取（我想實際上是 ~50，在極少數情況下可能是 1000）。

優點：

• 更自然的結構
• 更易於維護（例如刪除配方，檢查特定配方是否存在）
• 更容易添加字段（例如 timeOfCreation、comment、personalRating 等）

缺點：

• 從長遠來看會導致大量讀取

數組

我可以將每個已知的食譜（id 和 imageURL）保存在數組中的用戶文檔中（或作為單個子文檔“KnownRecipes”）。 這個數組可以是

recipesKnown: [{rid: 293ndwa, imageURL: image1.com, timeAdded: 8371201332}, 
               {rid: 9012831, imageURL: image1.com, timeAdded: 8371201871},
               {rid: jd812da, imageURL: image1.com, timeAdded: 8371201118},
               ...
              ]

優點：

• 每當有人想查看另一個用戶的列表時，我只需要閱讀一個文檔
• 讀取用戶列表可能更快

缺點：

• 很難更新特定的食譜（例如，有人想更改 imageURL：我需要在本地更改列表並將整個文檔作為更新發送到服務器 - 因為我不能只更改數組中的單個元素）
• 當用戶決定擁有大約 1000 個食譜時（這可能永遠不會發生，但有可能），可能會達到 Firestore 限制的 1MiB 限制。 一種可能的解決方法是創建一個單獨的文檔並將這兩個數組拆分為這兩個文檔。

---

對我來說，子集合的想法似乎是解決這個問題的更“干凈”的解決方案，但也許我遺漏了一些關於為什么其中一個解決方案優於另一個的論據。

我最常見的查詢如下（按重要性降序排列）：

• 用戶可以烹飪哪些食譜
• 將用戶可以烹飪的食譜添加到用戶列表
• 誰可以烹飪特定食譜（有食譜 -> 廚師子集合）
• 更新用戶可以烹飪的現有食譜

Answer 1

您的問題的答案取決於您想要達到的可伸縮性級別。

如果根據設計，您要存儲的子數據量有限且非常少，您應該使用數組，因為您減少了文檔讀取次數，這意味着成本更低。

如果你的子數據應該隨着時間的推移“無限”增加，你應該使用子集合。

如果您正在構建一個不應該在任何方向上擴展的數據庫（概念驗證、非常小的企業等），那就選擇您覺得更舒服的方式。

Answer 2

我正在研究同樣的問題...

其中一個問題是文檔中保存的數據是否會超過 1MB，這是文檔的限制。 研究一下它可以在 1MB 的純文本中保存多少，這真是太麻煩了。 盡管如此，如果它要大得令人難以置信，它最終還是會崩潰。 因此，如果您從大到大的方式考慮子集合。

如果我們必須使用 Firebase 元素邏輯，那么答案就是子集合。

我仍然認為主要的一點是提取的數據。 如果您致電用戶，您將直接提取該 MB 數據。 相反，它不會加載子集合，即使您加載了它，您仍然可以延遲加載。

我猜你正在做子收藏的那種設置。

Answer 3

key is an additional collection的 con/pro

key可以幫助避免重復； 但這需要考慮什么是重復的定義（可能會改變）；

array的無鍵行為可以通過自動識別來模擬。

ps @Thomas 在問題中列出的優點/缺點非常有幫助。