I have an application that has products, each product can have multiple brands and categories, we want in the future to know how many products are in some category or brand. To do this we thought it best to keep the _ids of categories and brands within the product, but if we do this every time we see one or more products we have to publish the brands and categories just to know the names. The simplest solution would save names and not _ids, but would no longer be reactive and our reports would not be 100% accurate
for now our top picks are
save _ids and publish the names of categories and brands when we want to see the products
save the names and if at some point the name of a category or brand changes save the old name and index all names
¿What should I do?
Thank you very much, I appreciate your attention, Greetings from Colombia.
if your access pattern is two sided (coming from either products -> categories or categories -> products), then I’d choose either of these for an N-to-N relationship:
keep separate collections for categories and products, where each collection stores a reference id of the other (same applies to brands)
this means your application developers have to be disciplined and maintain consistency in db code
keep a mapping table which stores pairs of category-product, just like in SQL
if this seems too relational to you, then perhaps you should consider an SQL solution
How many brands and categories will you have? With this number, is it really a problem to publish all of them to the client? It’s just _id and name pairs.
In the case of just wanting the names, why don’t you restrict which fields you are sending to the client? Just don’t include the fields which have the unnecessary category/brand _ids.
categories and brands are standard, they can be many but rarely will change, and stored inside the products and also into other things like product quotes and suppliers