爲什麼在Firebase中提供自定義引用密鑰而不是childByAutoId

Question

我剛剛學習Firebase，我想知道爲什麼需要自定義引用密鑰而不是僅使用childByAutoId。從文檔中的例子表明，這主要與以下類似：

{ 
    "users": { 
    "alovelace": { 
     "name": "Ada Lovelace", 
     "contacts": { "ghopper": true }, 
    }, 
    "ghopper": { ... }, 
    "eclarke": { ... } 
    } 
} 

但爲什麼不使用這樣的

{ 
    "users": { 
    "gFlmT9skBHfxf7vCBCbhmxg6dll1": { 
     "name": "Ada Lovelace", 
     "contacts": { "ghopper": true }, 
    }, 
    "gFlmT9skBHfxf7vCBCbhmxg6dll2": { ... }, 
    "gFlmT9skBHfxf7vCBCbhmxg6dll3": { ... } 
    } 
} 

雖然我寧願爲了提高可讀性的第一個例子。除此之外，Firebase功能和其他開發相關的功能（如查詢，更新等）是否會產生影響？謝謝！

Answer 1

火力地堡的childByAutoId方法是偉大的集合中生成的密鑰：

• 當物品需要通過他們的插入時間
• 責令凡項目沒有自然鍵
• 如果多次出現同一項目，則不會造成問題

在用戶集合中，這些條件（通常）都不適用：訂單不問題，用戶只能在收集中出現一次，而做的有一個天然的關鍵。

最後一個可能不清楚文檔中的示例。存儲在Firebase數據庫中的用戶通常來自不同的系統，通常來自Firebase身份驗證。該系統爲用戶提供了一個唯一的ID，在Firebase身份驗證中稱爲UID。該UID是用戶的唯一標識符。因此，如果您擁有一組用戶，那麼使用他們的UID作爲密鑰可以很容易地根據他們的ID找到用戶。在文檔示例中，只需閱讀鍵，就好像它們是該用戶的UID（友好的可讀版本）。

在你的例子中，假設你已經閱讀了Ada Lovelace的節點並想查找她的聯繫人。您需要在/users上運行查詢，這會在您添加用戶時變得越來越昂貴。但是在文檔模型中，您確切知道需要閱讀哪個節點：/users/ghopper。