How to denormalize / normalize data structure for firebase real-time database?

Question

I'm trying to get my head around how to structure data for a real-time firebase database. I read docs and some other questions about finding the following tips:

• data should be as flat as possible.
• be expensive on record to have cheap readings
• avoid data nesting
• data duplication may be ok

With that in mind, let me describe my specific use case. The frist user has the following attributes:

• Firstname
• Lastname
• Profile picture (large)
• Profile picture (small)

The user can create a story consisting of the following attributes:

• User
• Text
• Mark

A visual representation of the story may look like this:

My question is: how would you associate user information (first name, last name, small profile picture) with the story?

What I was thinking about:

• enter user_id in the history that contains the alien identifier for a specific user. To load a story, we would have to make two queries to the database, one to get the story and one for the user.

  {user_id: "XYZ", text: "foobar", timestamp: ...}

• put the first name, last name and a small image in the story. Only one query is required to display history. But we will have to update the history of each user when, for example, the profile image changes.

  {user_id: "XYZ", firstname: 'sandra', lastname: 'adams', smallProfilePicutre: '...', text: "foobar", timestamp: ...}

So, when several stories are created, and in most cases there are just reads, approach 1. will be expensive because we pay for two readings to show the story. Approach 2. would be more economical.

Here I would like your thoughts and ideas on this subject.

Answer 1

I'm with Jay here: you pretty much got all this in your question. A great description of the practice that we recommend when using the Firebase database.

Your questions boil down to: Should I duplicate user profile information in each story? Unfortunately, there is no single answer for this.

Most of the developers that I see will contain the profile information separately and simply save the user UID in the message as an unmanaged foreign key. This has the advantage of only updating the user profile in one place when it changes. The performance for reading a single story is not so bad: these two reads are relatively fast, as they cross over the same connection. When you display a list of stories, it is unexpectedly fast, since Firebase pipelines requests over a single connection .

But one of the first big realities I helped with the actual duplication of user data over stories. As you said: reading a story or a list of stories is as fast as in this case. When asked how they update user information in history (see Strategies here ), they admitted that they did not. In fact: they argued for many good reasons why they need historical user information for each story.

In the end, it all depends on your use case. You need to answer questions such as:

• Do you need historical information for each user?
• Is it important that you display the latest information to the user in older posts?
• Can you come up with a good caching strategy for user profiles in your client code?