假設我正在設計一個新的 Firestore 資料庫。假設我喜歡分層設計的想法，作為一個人為的例子，每個Year都有一系列子Weeks，其中每個都有Days。
今天檢索單個檔案的最高效的方法是什么？即 2021-W51-星期四
允許答案包括對模型的更改，例如“非規范化”日模型，使其包含year,week和dayName欄位（并查詢它們）。
否則，簡單的檔案參考可能是最快的方法，例如：
DocumentReference ref = db
.Collection("years").Document("2021")
.Collection("weeks").Document("51")
.Collection("days").Document("Thursday");
謝謝。
uj5u.com熱心網友回復：
任何標識要獲取的單個檔案的查詢與在 Firestore 操作的規模上執行相同操作的任何其他查詢的性能相同。館藏或檔案的組織在規模上根本無關緊要。您可能會看到小規模的性能波動，具體取決于您的資料集，但這并不是 Firestore 優化作業的方式。
所有集合和所有子集合都在檔案的 ID 上至少有一個索引，該索引以相同的方式作業，獨立于其他集合和索引。如果您可以使用其路徑識別唯一的檔案：
/db/XXXX/weeks/YY/days/ZZZZ
然后它的縮放比例與使用更扁平結構存盤的檔案相同：
/db/XXXXYYZZZZ
它在 scale 上沒有區別，因為集合上的索引可以擴展到無限數量的檔案，沒有理論上的上行限制。這就是 Firestore 的神奇之處：如果系統允許查詢，那么它將始終表現良好。您根本不用擔心擴展性和性能。索引會自動跨計算資源分片以優化性能（與成本）。
以上所有內容都適用于檔案的欄位（而不是檔案 ID）。您可以將檔案 ID 視為檔案的一個欄位，該欄位在集合中必須是唯一的。默認情況下，每個欄位都有自己的索引，并且可以大規模擴展。
對于像 Firestore 這樣的 NoSQL 資料庫，您應該以簡化查詢的方式構建資料，只要這些查詢可以由大規模操作的索引支持。這與 SQL 資料庫形成對比，后者針對查詢靈活性而不是大規模可擴展性進行了優化。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/394278.html
上一篇：FirebaseAuthRESTAPI和Firebase方法（例如（createUserWithEmailAndPassword等）之間的區別。我使用哪種方法？
下一篇：Firebase實時資料庫限制