CODEWITHSUNDEEP
mongodbdesign-patternsdatabase-design
it4rb
it4rb

Reputation: 166

mongodb: Embedded only id or both id and name

I'm new to mongodb, please suggest me how to correct design schema for situation like below:

I have User collection and Product collection. Product contain info like id, title, description, price... User can bookmark or like Product. Currently, in User collection, I'm store 1 array for liked products, and 1 array for bookmarked products. So when I need to view info about 1 user, I have to read out these 2 array, then search in Product collection to get title of liked and bookmarked products.

//User collection
{
   _id : 12345,
   name: "John",
   liked: [123, 456, 789],
   bkmark: [123, 125]
}

//Product collection
{
    _id : 123,
    title: "computer",
    desc: "awesome computer",
    price: 12
}

Now I think I can speed up this process by embedded both product id and title in User collection, so that I don't have to search in Product collection, just read it out and display. But if I choose this way, whenever Product's title get updated, I have to search and update in User collection too. I can't evaluate update cost in 2nd way, so I don't know which way is correct. Please help me to choose between them.

Thanks & Regards.

Upvotes: 2

Views: 204

Answers (1)

Philipp
Philipp

Reputation: 69663

You should consider what happens more often: A product gets renamed or the information of a user is requested.

You should also consider what's a bigger problem: Some time lag in which users see an outdated product name (we are talking about seconds, maybe minutes when you have a really large number of users) or always a longer response time when requesting a user profile.

Without knowing your actual usage patterns and requirements, I would guess that it's the latter in both cases, so you should rather optimize for this situation.

In general it is not recommended to normalize a MongoDB as radical as you would normalize a relational database. The reason is that MongoDB can not perform JOINs. So it's usually not such a bad idea to duplicate some relevant information in multiple documents, while accepting a higher cost for updates and a potential risk of inconsistencies.

Upvotes: 3

Related Questions