CODEWITHSUNDEEP
javascriptangularjsdatabaseperformancefirebase
AdskiRemote
AdskiRemote

Reputation: 25

Firebase storing data best practices

I'm developing an app which uses Firebase.

Do you know the best way to store data?

I have read their documentation on best practice for structuring data but doesn't offer advice on ids.

With my app once a user registers their user credientials are added and it creates a profile for them.

This stores into a 'profile' document as follows:

profile
      -> uniqueId (generated by Firebase)
                 -->  uid (unique Firebase generated uid)
                 -->  email
                 -->  password

However on my next document called 'settings' this is set differently...

The unique id doesn't exist and it uses the uid like this

settings
        ->  uid (Firebase user Id - not a unqiue id)
               -->   setting1
               -->   setting2
               -->   setting3

So in terms of best practice is it not better to have Firebase generate a unique id and then have the uid? Like the profile document?

Or I am doing this right?

Firebase documentation recommend keeping the structure as flat as possible. So my thoughts are it is. But then I am concerned about indexing. Would there be a performance issue with that?

Also if it is better to have the settings document like this...

settings
         -> uniqueId
                -->     uid (user Id)
                -->     settings1
                -->     settings2

Then does it not over complicate how settings are accessed for a specific userId. And shouldn't profile be set the same way as settings?

May be there isn't a better option but I'd be interested to hear thoughts.

Many thanks

Upvotes: 3

Views: 1004

Answers (1)

Jay
Jay

Reputation: 35657

The uid is a unique id so it's great to use their uid for parent node names in cases like a /users node.

Also, if each user has their own settings, then it's cool to include those into the /users/uid/ node.

'Flatter is better' is the motto but there are times when flattening may actually overcomplicate things. In this case, a user logs in and their settings are read. Done. You won't be query-ing it or doing any kind of cross reference lookups so just keep it with the other user data.

In general your are on the right track:

Using auto created id's is good practice - this allows you to disassociate node names from the data it contains.

Things like email addresses and people's names, and really anything that could change are not the best node names, as they may be referenced in 200 other places in your structure and if the email address changes, for example, you'll have to seek out 200 places and perform updates. (email addresses have special characters as well so you have to massage them to make them work anyway.)

With a auto-generated node name, you change it once.

Upvotes: 6

Related Questions