Saving Data on Android

Best prac/ces for data structure
The entire database is a big JSON tree with multiple nodes. When pushing new data 
to the database you either create a new node with an associated key or update an 
existing one. Therefore there is the danger of creating a deeply nested structure. 
Firebase Realtime Database allows nesting data up to 32 levels deep but that doesn't 
mean that this should be the default structure. When thinking about data structure 
you need to think about how your data is going to be consumed, you need to make 
the process of saving and retrieving as easy as possible.
If you have very complex structures with a lot of nesting you fetch all the data every 
time you read from the database, which is not needed in most of the cases. If you 
want to get the data from a specific node you get all the data below that node as well. 
Take a look at this restaurants structure for example:
{ 
  
"restaurants"
: { 
    
"first_restaurant"
: {}, 
    
"second_restaurant"
: {}, 
    
"third_restaurant"
: {} 
  } 
}
Fetching the restaurant's data would get you all of its child nodes data as well. In 
addition, when you grant someone access at a node in your database you also grant 
them access to all of its children's data. You can limit this by specifying how many 
restaurants you want to fetch or to fetch only restaurants that satisfy some condition 
but in general, when you're loading data you're loading all of it. Because of this, it's 
good practice to keep your data structure as flat as possible.
Another good practice would be that you organize your data in a way that you don't 
fetch the data that you're not rendering on the UI. If you split your data into separate 
paths you can be more specific about what data you want to fetch. Traditionally, you 
would have a set of data and you'd build your UI on top of that, but with Firebase, 
since it's easy to write data, people build their UI and then they start building a data 
structure from the app. This flat data structure affects the performance in a good 
way since you don't need to fetch extra data that you won't use, which allows the UI 
to stay responsive and fast.
Saving Data on Android
Chapter 12: Introduction to Firebase Realtime Database
raywenderlich.com
212

---

Generally, there's no right or wrong approach to structuring your data. Storage is 
cheap. You can have a million copies of the exact same string field in the Realtime 
Database and it will cost you almost nothing but the problem appears when fetching 
this data. With a little bit of practice, you'll be able to judge better what makes sense 
to nest and what doesn't.