There is no disagreement there.
You don't want to be storing all the possible combinations though. You only want to be storing the available options which result in all the different combinations.
Could you please demonstrate that then, as so far you haven't shown how that's achieved.
Again, I really can't say which db schema is "better". That will depend on so many specifics of the project I don't know. Like how a "product" is defined, does it have a unique number to identify it, on what is that number based, what attributes are possible, how are they going to change in the future, what technical limitations are there, which databases are available, etc. I am just suggesting one possible scheme.
1 Shirt Green Small $20
2 Shirt Green Medium $22
3 Shirt Green Large $24
4 Shirt Blue Small $22
5 Shirt Blue Medium $24
6 Shirt Blue Large $26
7 Jeans Green Large $20
One way to achieve a more normalized db schema:
1 Shirt $20
2 Shirt $22
3 Shirt $24
4 Shirt $26
5 Shirt $30
1 Size Small
2 Size Medium
3 Size Large
4 Color green
5 Color red
6 Color blue
Not sure I understand what you mean. In a normalized db schema, it's possible to get out whatever you want joining tables together in various ways. Of course, depending on which schema you choose the queries you have to write to get something out of the db might be more or less complicated, but I'll leave that to the programmers to figure out
It has more to do with it than you obviously think. How your store your data can have a big impact on the different ways the data can be displayed.
just blame the spelling checker in my browser :)
By the way, can I ask why you refer to the price as the "prize" (if that's what you're referring to). I don't mean to have a go at you, but I want to make sure that we're both talking about the same thing here.