1. Home
  2. Firebase
  3. Firebase: Data Organization in Real-time Database

 Firebase: Data Organization in Real-time Database FIREBASE

Firebase: Data Organization in Real-time Database  


Firebase: Data Organization in Real-time Database

Firebase: Data Organization in Real-time Database

We already know that the data in the Firebase is stored as in the JSON file format. So, what is the meaning of JSON format in the Firebase Real-time Database?

Structure of Database

  • Creating a well-structured database requires quite a bit of forethought. It means we need to plan for how data is going to be saved and later retrieved to make that process as easy as possible.
  • In a Firebase Real-time database, data is stored as JSON objects. We can think of the database as a cloud-hosted JSON tree.
  • There are no tables and records, which means it is a NoSQL database.
  • Data stored can be represented as certain native types in the database that correspond to available JSON types to help us write more maintainable code.
  • When we add data to the JSON tree, it becomes a node in the existing JSON structure with an associated key.
  • We can provide our own keys, such as user IDs or names, or they can be provided to us using push() function.

Let's take an example to understand how the data looks like in Firebase Realtime Database for JSON trees. Let's consider the example of storing data for a chat application. This chat application allows users to store the basic profile and contact list. The user profile would be located on a path such as Users/$uid. The user is a node in it and will have a sort of primary key associated with an ID. So, we can access each one uniquely.

 
  1. {  
  2.   "Users": {  
  3.          "Student":{  
  4.                    "name":"Deepak Kumar",  
  5.            "contacts":{"Faculty":true},  
  6.         },  
  7.         "Faculty":{?},  
  8.         "Staff":{?}         
  9.   }  
  10. }   

Everything which is under Users would be a specific node to the Users, and we would access them using a reference like Users.Students, Users.Mstudent, and Users.Tsudent etc. This is the basic tree structure, and what it looks like and what we notice is that it has a lot of nesting. In Cloud, Firestore does not have as much nesting, and nesting can cause some performance issues.

So, in the above example, Student is a node under Users. Name and contacts are nodes under Student and Faculty, and Staff is under Users.

Avoid Nesting Data

The nesting can cause some performance to decrease. So, we have to avoid nesting data as much as possible. It is necessary, but we avoid it, especially if we have a large dataset because there could be a performance hit. We have to try to make our data structure as flat as possible.

Example:

 
  1. {  
  2.      "Chats":{  
  3.           "One":{  
  4.                "title":"W3Tpoint",  
  5.                "message":{  
  6.                "m1":{  
  7.                       "sender":"Deepak", "message":"Send your daily report"  
  8.        }  
  9.                "m2":{?}  
  10.                //A very long list of messages  
  11.                }  
  12.           },  
  13.           "Two":{?}  
  14.      }  
  15. }  

It is a poorly nested data structure because iterating the sub children of the child node of the Chats node needs to get a list of conversation titles. So, this could require potentially hundreds of megabytes of messages. In this example, if we are iterating through the data, then it will be very problematic.

Flatten Data structure

For avoiding nested data, try to flatten in our data structure. Splitting the data into a separate path would be a better way. So, it can be efficiently downloading separate calls as it's needed.

  1. {  
  2.   //Chats contain only meta info about each conversation  
  3.   "chats":{  
  4.     "one":{  
  5.       "title":"W3Tpoint",  
  6.       "lastMessage":"Student:whatever",  
  7.       "timestamp":1449884177228  
  8.     },  
  9.     "Two":{...},  
  10.     "Three":{...}  
  11.   },  
  12.   //Messages are seperate from data we may want to iterate quickly but still easily  
  13.   // numbered the messages and queried, and organized by chat conversation ID  
  14.   "messages":{  
  15.     "one":{  
  16.       "m1":{  
  17.         "name":"Faculty",  
  18.           "message":"Send your Report",  
  19.           "timestamp":1459754195874  
  20.       },  
  21.       "m2":{...},  
  22.       "m3":{...}  
  23.     },  
  24.     "Two":{...},  
  25.     "Three":{...}  
  26.   }    
  27. }  

 

#askProgrammers
Learn Programming for Free

Join Programmers Community on Telegram

Talk with Experienced Programmers

Just drop a message, we will solve your queries