Question on Item Variations / Modelling data

Open Q&A
, ,
1

I have a question about this guide on item variations.

In that, we have shirt color variations. Which is why, we end up

  • creating a record for each variation (color field)
  • with each variation still having details about all variations (color_variants field).

So, let us say a shirt has 2 color variants. So for each shirt, we end up having 2 records.

This bit is clear for me.

Extending the same example - let us say each shirt has material variants along with color variants. So a shirt can be using Cotton or Polyester material and Red or Blue in color.

Question 1 - Does this mean I now need to create 4 records for a shirt? 2 variants of colors multiplied by 2 variants of materials? My index actually has multiple attributes that can serve as variants. Which would imply that the # of records per entity (clothes in our scenario) will increase exponentially as we end up adding new attributes that can serve as variants. Is that expected behaviour or there is a better way to model multiple attribute variants?

Question 2 - In my index, the “clothes” can undergo updates. Let us say we frequently update the name of the shirt. This is NOT a variant - just a regular attribute that would be seen on each record / variant. Does this mean that we have to update EACH variant now? If so, is there a better way to approach modelling of such data? I understand Algolia does not have the concept of RDBMS and having having all parent data on variant is preferred over having “references” to parent - but if we have large number of variants (based on the answer to Question 1 above), we can end up having large number of records to update too…

We do use the regular attribute as well as each variant related attribute for searching / querying / faceting - so we definitely need them stored in Algolia but I am not sure if following the guide of Item variations is the way to go about it. I am wondering how existing apps model this since it does not seem like an uncommon use case.

If it plays a role - we are using React InstantSearch for our client / UI.