Firebase database design best-practices

[Kirtan Thakkar]

In most of the examples I have seen a structure like this when we have data nested with something like groups:

So whenever you want to load basic information you don't need to load all the whole group object including tons of messages which is a huge object. But, while considering this modal, I ran into one another modal which fairly solves the issue of loading all the messages for some basic group details. Here, it is:

I can easily load all the things which are necessary without loading the other. This modal also seems to work fine without issues. It says we have all the group information under a node and achieving the benefits of nested structure of firebase, which sql-background people mostly go for at first.

Sometimes, It is more of a personal choice, but one has to decide based on scaling and others parameters.

Which one is better? Which can be considered as the best-practices? What are the tread-offs between these structures?

Thanks,

Kirtan

[Kato Richardson]

Hi Kirtan,

Both are great. The mantra here is: Store the data how you will read it.

So if you want to iterate groups to get a list of names, the second structure here would perform poorly (since iterating groups requires loading all the messages). Of course, you could simply duplicate the group names or store those somewhere else.

If you never iterate groups, or always want members/, messages/, and meta/ when you do, then this is perfect.

☼, Kato

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/89630a7a-0033-49c5-8424-14b641c125a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

[Kirtan Thakkar]

Hi Kato,

Thanks for great information! With the second method iterating groups is a pain. In a structure like where groups are listed most of the time as a key:true type in a users node. So, that might never required. But, still need to take care if I ever wanted to iterate groups. 

Thanks,

Kirtan

On Wednesday, August 24, 2016 at 1:07:07 AM UTC+5:30, Kato Richardson wrote:

Hi Kirtan,

Both are great. The mantra here is: Store the data how you will read it.

So if you want to iterate groups to get a list of names, the second structure here would perform poorly (since iterating groups requires loading all the messages). Of course, you could simply duplicate the group names or store those somewhere else.

If you never iterate groups, or always want members/, messages/, and meta/ when you do, then this is perfect.

☼, Kato

On Tue, Aug 23, 2016 at 11:47 AM, Kirtan Thakkar <kirtant...@gmail.com> wrote:

In most of the examples I have seen a structure like this when we have data nested with something like groups:

So whenever you want to load basic information you don't need to load all the whole group object including tons of messages which is a huge object. But, while considering this modal, I ran into one another modal which fairly solves the issue of loading all the messages for some basic group details. Here, it is:

I can easily load all the things which are necessary without loading the other. This modal also seems to work fine without issues. It says we have all the group information under a node and achieving the benefits of nested structure of firebase, which sql-background people mostly go for at first.

Sometimes, It is more of a personal choice, but one has to decide based on scaling and others parameters.

Which one is better? Which can be considered as the best-practices? What are the tread-offs between these structures?

Thanks,

Kirtan

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/89630a7a-0033-49c5-8424-14b641c125a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.