Data Organization in Firebase Real-time Database

In our previous section, we understood how to setup a Firebase console and Android application to use the Real-time database. In this section, we will talk about how the data is organized in Firebase or Firebase 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 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 see 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. 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.

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:

It is a poorly nested data structure because iterating the sub children of the child node of 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.