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:
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.
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)