Favorite funcionality

Working with Data
1

Hi all Green again, Im trying to implement a “favorite” functionality and I have basically two solutions, but cant say which one would work best. Here is the use case:

I have a collection of Aliments that users can browse. The users can then put one or more Aliment as a favorite. When the user enters his favorite section, it must be able to do the same queries done when looking for a “public” Aliment (before is moved to the favorite section). The queries are by name and tags.

My two solutions are the following:

  1. The act of put an Aliment as favorite will duplicate the aliment and set the user id as the owner of that aliment. In this case I can keep the existing queries and just add the condition on the user id if the queries come from the favorite section where only the favorite Aliment must be shown. I like this solution, but in the event a public aliment gets an update (for example the addition of a translation) the users will not see this update in their favorite collection. Of course these updates are not frequent, so when a new translation is added to a public aliment, I can go and update all the Aliment copied in the favorite collection of each user.

  2. Use an AlimentFavorite collection that holds the userId and the AlimentId and use an aggregation + lookup. The query would add the filter conditions (name and tags) and it will do a subpipeline lookup to match only the aliment where an AlimentFavorite exists (more like relational database style). I was also thinking that, if in the future I need to shard, then these lookups could be across shard, which will then degrade the query performance (correct me if Im wrong)

Thank you

Green

2

Hello @Green, I think the first approach you have explained looks more appropriate to me. This is because the updates on the public aliment are not frequent. These updates can be applied to the user favorites once daily, for example, for all users and updated aliments as a batch job. Also, your querying will be efficient (simpler and better performant). It is not an uncommon scenario to store duplicated data across collections, especially if the updates are infrequent.

The second approach needs creating data (user and aliment) in a separate collection (this is also duplicating data), and querying with aggregate $lookup can be complicated and tax on the performance.

3

@Prasad_Saya Thank you! The first approach look better to me too.