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

分类表 <= 商品表 <= 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)