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

FirebaseのchildByAutoId方法は、コレクション内の鍵を生成するための素晴らしいです：

アイテムは彼らの挿入時間によって項目が自然キー

を持っていない

を注文する必要が

• 同じアイテムが複数回出現する場合に問題がない場所

ユーザーの集まりでは、これらの条件は適用されません（通常は適用されません）。ユーザーはコレクションに一度しか表示されず、アイテムはには自然なキーがあります。

最後のものは、ドキュメントのサンプルからはっきりしない場合があります。 Firebaseデータベースに保存されているユーザは、通常、Firebase認証のもとで別のシステムから取得します。そのシステムは、ユーザーに一意のIDを与えます.Firebase認証の場合、UIDと呼ばれます。このUIDは、ユーザーの一意のIDです。したがって、ユーザーの集まりがある場合、そのUIDをキーとして使用すると、IDに基づいてユーザーを簡単に見つけることができます。ドキュメンテーションサンプルでは、​​あたかもそのユーザーのUID（あたたかく読みやすいバージョン）であるかのようにキーを読み取るだけです。

あなたの例では、Ada Lovelaceのノードを読んで、連絡先を検索するとします。 /usersのクエリを実行する必要があります。これは、ユーザーを追加するにつれてますます高価になります。しかし、ドキュメントのモデルでは、正確にどのノードを読む必要があるかを知っています：/users/ghopper。