0

I am building a firebase web application. Here is a simplified Firestore structure:

...
   - ...
        ITEMS
           - item1
                PHOTOS
                   - photo1
                        uid
                VIDEOS
           - item2

USERS
   - uid1
       displayName
       ... 
   - uid2
   - ...

When someone accesses a photo or video I want to display the appropriate displayName and profilePhoto for that item.

I see two possible solutions:

  1. Store only user UID in items. On every load, get user data from USERS collection or Then loop in user's UIDs and connect them with item UIDs. This would be done on every call. When users update displayName or profilePhoto, there wouldn't be any problem.

  2. Store user UID, displayName, and profilePhoto path on the item. When users update data I would need to run a cloud function which would then update all items with new data.

How should I approach this and is there any other approach that I should consider? I lean towards the second solution.

Alex Mamo
  • 130,605
  • 17
  • 163
  • 193
cko8
  • 11
  • 3

1 Answers1

2

What you have are the two most common approaches. The first is commonly referred to as performing a client-side join, while the second is duplicating/denormalizing the necessary data.

Neither is pertinently better than the other, but folks who are new to NoSQL databases are typically hesitant to duplicate data so tend to gravitate to performing client-side joins.

As you gain experience in NoSQL data models, you'll learn the right questions to ask yourself. For example: how often do a display name and profile photo change in my app? If that happens infrequently, duplicating those values in each item will make my reading code a lost simpler, faster, and more scalable.

For more good reading/watching on this:

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • Thank you very much for your quick answer. I am aware of data denormalizing and i am using it in the database. I just wasn't sure in this particular case, because as the app scales and becomes more complex with the user content there will be a lot of read and writes for just one name change. Those articles were really helpful. I think that i will go with eventual consistency approach with limit on the change rate. – cko8 Nov 24 '21 at 20:09