CODEWITHSUNDEEP
firebasefirebase-realtime-databasenosql
Dani
Dani

Reputation: 3637

Firebase database structure - denormalized data?

I read a lot about nosql databases lately. I get that rule of thumb is to structure the data based on our view (of course, depends on the use case).

Now, let's say that we have a social app and the user has a profile but he also creates posts and we have to store them in the database.

So, I see some developers choose to do that like so:

Posts
-----UserID
-----------PostID
-----------------username: John
-----------------profileImage: https://...
-----------------posted_photo: https://...

This totally fits the structure base on the view. We'd go into posts and our userID and we could get all the data that our view needs. Now my question is, what happens when the user has made 100K posts and he decides to change his profile photo for example. All of his posts so far contain his old photo, so now, we have to write a method that would cycle through 100K of posts (or all of his posts in general) and update his photo. In 2 hours, he decides that "Nah, I don't like this photo, I'd change it back" and we have to make another 100K queries.

How is that (denormalized data) ok? Sure, its easier, its flat but then we have to make ridiculous amounts of queries to change a single profile photo. What's the way to handle this really?

Upvotes: 1

Views: 166

Answers (1)

Devid Farinelli
Devid Farinelli

Reputation: 7544

I've done this storing user's data in a place and setting just the userID as post attribute.

posts:
    userID:
        postID:
            userID: 'user1',
            attachedImageURL: 'http:..',
            message: 'hey',
            reblogID: 'post4',
            type: 'audio|poll|quote'
users:
    user1:
        name: 'john',
        profileImage: 'http..'

It requires one more query to Firebase to retrieve user's profile data but it's a good way to solve this. It really depends on how you want to use those data.

Upvotes: 3

Related Questions