Firestore generated key versus custom key in a collection?

Asyl Paitesh :

I am using Cloud Firestore database in my Android app and I have different documents within collections like: uid for users, pushed keys for restaurants and numbers for my recipes.

My db:

users
  uid1
  uid2
  ...
resturants
  pushedId1
  pushedId2
  ...
recipes
  0001
  0002
  ...

For the users I understand to use the uid's but is better to use Firestore pushed ids for my restaurants? Is this a convention or why to use it?

I also tried to generate unique keys using UUID Class but is more easy for me to use only numbers for my recipes. Is this a bad approach?

Any help will be appreciated, thank you!

Frank van Puffelen :

By using predictable (e.g. sequential) IDs for documents, you increase the chance you'll hit hotspots in the backend infrastructure. This decreases the scalability of the write operations.

Cloud Firestore has a built-in generator for unique IDs, that is used when you call CollectionReference.add(...) or CollectionReference.document() (without parameters). The ID that it generates is random and highly unpredictable, which prevents hitting certain hotspots in the backend infrastructure.

Using UIDs for the documents of users is a fine substitute for Firestore's built-in generator, since the UIDs already have a high level of entropy: you can't predict the UID of the next user based on knowing the current user. In such a case, using the UID (or otherwise the natural key of the entity) is a better approach, since you can perform direct lookups of the documents instead of having to query.

See this discussion on the firebase-talk mailing list where some of the engineers working on Firestore explain in more detail.

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=473358&siteId=1