I've been brainstorming on a specific problem for a while and today I've thought of a solution. But am not too sure about it. Hence this question for feedback and suggestions.I'll use the simple example of a product T-Shirt.The T-Shirt has multiple options:Color: White, BlackSize: Small, Medium, LargeNow in the case of a White T-shirt, there is no Large and Medium. So Large and Medium option should not be available when selecting White.This means that if you first select Large or Medium. Then White should not be available.Previous implementation was done as a tree structure. So you always have to select Color then Size. But it's not really a tree the way I see it.My idea was to create a list of rules.pseudo code:rule1: if color is white, sizes not allowed are [large, medium]//then generate the opposite rules based on rule1.rule2: if size is medium, color not allowed are [white]rule3: if size is large, color not allowed are [white]store rules in databaseWhen you are dealing with products that have many options this could get complicated, that's why I thought generating the other rules based on the first rule can reduce the complexity.Thoughts anyone?Update:Someone remarked below and I realised I used the wrong example. It's not a product which has a SKU and stock level. It's a service. A better example would be a configurable computer. Many different CPU, RAM, GPU, etc combinations. Which all produce different price and depending on specific motherboard or some specific selection, not all CPUs and/or RAM etc are selectable.Update2:The products/services each have around 7 options. Each option can have between 2 - 7 values. A matrix structure as suggested, would become complex IMO.Also we've moved away from having a price for each single variation (which was ridiculous to manage) to having formula's to generate prices dynamically.There was always an issue with the DB load because of the tree structure. Each time an option is selected it has to fetch the values of the subsequent options. Each time you add a new value to an option you also duplicate a lot of the subsequent options. So it gets out of hand really quickly.To go into more details my solution was to use a document based database (NoSQL)You would have a Products or Services collection.Each product/service would look something like this:{  product: T-Shirt,  options: {    size: [],    color: [],    pattern: [],    ... about 4 more  },  rules: [....],}Initially you just load all the options in the interface. Then as you make selections you run the rules to disable the specified option values.Using such a structure seems to me that it would have less overhead by having the rules embedded in each product/service instead of having a large relational table with all the options (which is already massive).The client side benefits because it doesn't have to query the DB each time an option is changed.
Modeling complex product options
design