Quote Originally Posted by Wardrop View Post
I don't think that would work too well. A product could potentially have over 10 multiple choice attributes, each with potentially over 10 values - assuming they all modify the price in some way, you start hitting 1000's of possible combinations (in my solution it would only store the 100 possible values, not all the combinations). Pre-calculating all of the combinations and storing them in a table is incredibly inefficient - but on that note, if you're dealing with SKU's that's essentially what you have to do anyway. But on top of that, how would you know which product/price goes with which combination of attributes?

I just see your solution as being more complex to achieve a less flexible result - in fact I don't think it would work at all when you consider variable pricing.
Could you also explain why you think putting prizes in the product table wouldn't work?

I would think that if you have a green T-shirt in size XL, then that's one product with one prize. So that T-shirt has an unique Id and a unique prize. Put the Id, product name and prize in one table. Following normalization rules, put the attributes in different tables with foreign keys.

One way or the other, these 1000's of possible combination's will be there. Whether you put them in one table or in 10 tables. I don't know the specific requirements of the project of the original poster. Depending on those, you would choose a very normalized approach or otherwise a less normalized one. I'm also not familiar with the prizing scheme used. Probably depending on that you could choose a different approach

@allspiritseve: yes, I can see how an AEV approach makes the search queries a bit more difficult. Maybe looking into how different tagging schema's are used in the bigger web apps like Delicious would be interesting.
A somehwat older article, but still interesting