creating schema vs adding an additional field?

Viewed 112

I want to store featured products like staff picks, featured products of each category in my system that will hold at most 10 documents. My priority is read performance over write performance but I also want to have an efficient storage system and I have three ways to do it in my mind:

  1. Create a boolean field such as is_bestseller, is_staffpick in Products schema and query for it.

    I think this is the simplest way to do it but I think it would require an additional query to check if the at most 10 limit has been reached.

  2. Create a FeaturedProducts schema that holds references of product ids.

    This is useful in the sense that if I want to add some additional info such as a featured product within the featured products then I could simply add a field in this schema. It would also be easy to check the at most 10 documents limit. I think this makes it more scalable but at the cost of performance?

  3. Create a FeaturedProducts schema that will hold all the needed data.

    I think performance wise this would be the best but I'm not sure if this is an efficient way to store data. Basically, I would just duplicate the data of a product and store it. Obviously, if I have to update product details then I have to update it in two places now but the read-to-write ratio heavily favors reading so I am willing to do this even if it's gonna require more logic regarding updating and deleting products. Also it would be easy to set at most 10 documents limit.

I tried to look for some examples regarding featured products but couldn't find anything useful. I am not sure what the best practice is here and which way to go about so any kind of help is appreciated.

2 Answers

The rule of thumb when modeling your data in MongoDB is:

Data that is accessed together should be stored together.

Havin that in mind I considered The Extended Reference Pattern a great options for you use case, here is a example from the MongoDB Blog.

Considere an e-commerce application where you have user collection, order collection and others. Where users and orders has a 1-N relation, embedding all of the information about a customer for each order just to reduce the JOIN operation results in a lot of duplicated information.

Instead of duplicating all of the information on the customer, we only copy the fields we access frequently.

Extended Reference pattern

This schema will have height read performance, because all the information will be store in a single document, at the cost of some duplicate data, but that is not completely bad considering that it can sever as history data.

Useful information:

A potential solution is to use an index here so that you can maximize your query performance. You would create an additional boolean flag (as you indicated in your first solution) then index that query, with a cursor that limits the number of returned values.

For more ways to increase your query performance check out the official Mongo docs here. If you're curious as to how much more performant your queries become, you can use Mongo's explain() method to get benchmarks (more info here) and compare approaches.

Best of luck!

Related