属性就颜色和尺码

颜色表
颜色id  颜色值

尺码表
尺码id  尺码

库存表
产品id  颜色id  尺码id  库存  价格

属性不固定

属性分类表
分类id  分类名

属性表
属性id  分类id  属性名

库存表
产品id  属性id(多个逗号隔开)  库存  价格

实体－属性－值模型（EAV模型）

首先俩表即可 即 商品表 + 商品属性表
商品表和属性表是1对多的关系
所以商品表保存一些固定属性 比如商品名字 总库存 剩余库存之类等等 具体情况而定 比如你说的裤子外套等
属性表则保存比如你说的颜色 尺码 当前属性下的库存之类的
不知道你有思路的没？

分割线---------------------------------

首先商品分类 ：-衣服-裤子-1号裤子==当前裤子有属性-颜色
                                            -尺码
                                            等等
                      -2号裤子
                      -3号等。。
                  -裙子-同上
                  等等。。
             -零食

我的思路小商场基本就是这些
第一个表你保存 商品固定属性 比如 id 1 名称 1号裤子
第二个表 和第一个表关联 1对多 一个商品对应多个属性 
那么 数据就是 sid 1 关联第一个表的id 1  然后 颜色绿色 库存 999 尺码xl
sid 1 关联第一个表的id 1  然后 颜色红色 库存 999 尺码 m
sid 1 关联第一个表的id 1  然后 颜色红色 库存 888 尺码 l

当你查的时候 就对应颜色 对应尺码 对应库存 当然颜色 尺码都存数字 配置比如绿色为1 红色为2 具体你再处理下

仅供参考  哈哈 我也是菜鸟

最近也在思考这个问题,网上看了一些资料,得出的总结:

分类表 <= 商品表 <= SKU表(库存表)
分类表 <= 属性名 <= 属性值
商品表 <= 商品和属性关系表 => 属性名|属性值

分类表:
(商品分类编号, 分类名称, 父分类编号)
(1, 男装, 0)
(2, 裤子, 1)
(3, 外套, 1)
(4, 内裤, 1)
(5, 袜子, 1)

商品表:
(商品编号, 商品名称, 商品分类编号, 卖家编号, SPU销量, 评论数)
(1, '裤子名', 2, 1, 0)
(2, '外套名', 3, 1, 0)
(3, '内裤名', 4, 1, 0)
(4, '袜子名', 5, 1, 0)

SKU表(库存表):
(SKU编号, 商品编号, SKU属性, 价格, 库存, SKU销量)
(1, 1, [1,3], 99, 400, 0) 其中 [1,3] 表示 "颜色为黑色,尺码为X"
(2, 1, [1,4], 99, 200, 0) 其中 [1,4] 表示 "颜色为黑色,尺码为XL"
(3, 1, [2,3], 99, 300, 0) 其中 [2,3] 表示 "颜色为白色,尺码为X"
(4, 1, [2,4], 99, 100, 0) 其中 [2,4] 表示 "颜色为白色,尺码为XL"
上面只列出商品1这个分类的4个SKU.

属性名:
(属性名编号, 属性名, 商品分类编号, 父属性编号)
(1, 颜色, 2, 0)
(2, 尺码, 2, 0)
(3, 品牌, 2, 0)
上面只列出裤子这个分类的3个属性名.

属性值:
(属性值编号, 属性值, 属性名编号)
(1, 黑色, 1)
(2, 白色, 1)
(3, X,  2)
(4, XL, 2)
(5, 七匹狼, 3)
(6, 九牧王, 3)
上面只列出裤子这个分类的6个属性值.

商品和属性关系表:
(自增编号, 商品编号, 属性名编号, 属性值编号)
(1, 1, 1, 1) 商品1颜色为黑色
(2, 1, 1, 2) 商品1颜色为白色
(3, 1, 2, 3) 商品1尺码为X
(4, 1, 2, 4) 商品1尺码为XL
上面只列出商品1的4个属性关系.

商品和属性筛选表:
(商品编号, 商品属性)
(1, [1,2,3,4])
用SQL全文检索实现筛选.
如:
select * from 商品表 
inner join 商品和属性筛选表 
on 商品表.商品编号 = 商品和属性筛选表.商品编号
where 商品表.商品分类编号 = 2 
and 商品和属性筛选表.商品属性 MATCH '1 3'
order by 商品表.评论数 DESC LIMIT 10 OFFSET 20;

商品搜索表:
(商品编号, 商品标题和内容)
(1, [二元分词])
用SQL全文检索实现搜索.

里面有这么一些表结构设计思想:
名值: id, name, value (用于实现自定义字段如属性的存储)
父子: id, pid (用于实现关系树如分类和子分类的存储)
其中"名值"的思想应该就是EAV(Entity-Attribute-Value)实体属性值模型思想.
留意过WordPress数据表的也会看到类似设计:

wp_postmeta(meta_id,post_id,meta_key,meta_value)
wp_commentmeta(meta_id,comment_id,meta_key,meta_value)
wp_usermeta(umeta_id,user_id,meta_key,meta_value)
wp_options(option_id,option_name,option_value,autoload)

"父子"存储无限极分类:

wp_term_taxonomy(term_taxonomy_id,term_id,taxonomy,parent)