我將不勝感激有關如何構建存盤在應用程式中的資料的一些指導。雖然第一種方式有一些原因，但我擔心第二種方式無法有效運行。
簡化后，該應用程式將包含按州列出的地點串列。主要用例是查看選定州內的地點。第二個用例是個人用戶可以將他們喜歡的特定地點保存到他們的個人資料中并一次查看它們（在一個串列中顯示所有狀態地點）。
選項 1 - 保存在一個“地點”集合中的地點，該集合具有“狀態”欄位。
主要用途：為了按狀態顯示這些地方，應用程式將查詢“狀態”欄位與狀態匹配的位置。
二次使用：當用戶保存地點時，應用程式會將docID每個地點的資訊保存到用戶的個人資料中，需要檢索每個地點以顯示地點串列。
選項 2 - 每個州有一個集合。
主要用途：為了按狀態顯示這些地方，應用程式將拉取查詢中的所有檔案并將它們列出。
二次使用：當用戶將地點保存到用戶的個人資料中時，應用程式會將docID每個地點的資訊保存到用戶的個人資料中，分布在不同的集合中，需要檢索每個集合以顯示地點串列。
目標：
- 使用相同的地點檔案同時出現在狀態串列和用戶的組態檔中。
- 在輔助用例中盡可能減少呼叫次數/速度。
我一直在查看 Firestore 資料存盤指南，但如果有經驗的開發人員對此資料結構提出任何想法，我將不勝感激。
uj5u.com熱心網友回復：
構建 Firestore 資料庫沒有“完美”、“最佳”或“正確”的解決方案。我們通常根據我們打算執行的查詢來構建資料庫。
關于將所有地點存盤在單個集合中與每個狀態具有一個集合，請注意在速度或成本方面沒有區別。您將始終需要支付與您的查詢回傳的檔案數量相等的讀取次數。但是，如果您需要在您的應用程式中顯示，例如，所有州的所有地點，那么每個州都有一個集合，則需要為每個州單獨查詢。
此外，關于在用戶個人資料中保存地點串列與僅存盤 ID，這是一個計算問題。您應該測量地點內的資料更改的頻率。請記住，如果一個地方發生了變化，那么您應該在它存在的所有地方更新該資料。因此，如果不是那么頻繁，那么您可以保存整個地點物件，否則，只保存 ID。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/450876.html