CODEWITHSUNDEEP
database-designfirebasefirebase-realtime-database
Isaac Gregson
Isaac Gregson

Reputation: 2075

Using Firebase User UIDs for keys of related DB entries - Good or Bad Practice?

Are there any problems with using a user's UID (which is generated by Firebase upon user creation via Firebase Auth) as the key for associated database entries?

For example, here: 

/config/user.uid/configObject

...each user has one config entry. Due to Firebase's database rules (where settings on a parent node apply to all child nodes) it's often necessary to create a separate config tree (following the example, where a /users tree needs to be read and write protected).

The only reason I can see that this might be bad practice is if the user's UID ever changes... Does Firebase guarantee that this will never happen? Anything I'm missing?

Upvotes: 4

Views: 872

Answers (1)

whatsthatitspat
whatsthatitspat

Reputation: 721

The UID for a particular user will never change (though they did change the format a few months ago; the old format included the provider).

It's a good practice, a necessary one in many cases, and probably recommended somewhere. You'll want to denormalize user info into multiple nodes for better performance and for authorization as you mentioned. It might look something like this in pseudo code/rules:

- users_private (.read: $uid == auth.uid)
  - $uid
    - email

- users_public (.read: true)
  - $uid
    - name
    - photo

- users_roles (.read: dependent on some other rules)
  - $uid
    - is_admin
    - is_editor

Upvotes: 3

Related Questions