简介
一般情况下我们使用5张表就可以解决基本的需求了：
- 商品分类表：category
- 商品表（即SPU表）：表：product
- 商品规格表（即sku表）：product_specs
- 属性key表：attribute_key
- 属性value表：attribute_value
具体设计
概述
spu表和sku表实现不同商品的存储:spu表使用attribute_list字段保存属性集合，查询时使用product_id和product_specs去sku表中获取的具体的单品信息。 spu表中可以增加一些商品的公共信息字段，例如名称、发布的商家、发布日期、上架状态； sku表中增加一些每个单品不同的字段，比如不同的单品有不同图片和名称或者详情说明等等，反正根据业务进行扩展
核心思路就是把弹性字段使用json存储，这样设计的优点是数据表结构稳定，不用在商品增加属性后增加字段， 缺点是商品数据的解析复杂，弹性字段需要在业务代码中进行处理，增加了业务代码的复杂度。
商品分类表：tb_product_category
该表主要是描述商品的分类。此表采用无限层级树状数据结构，程序使用递归算法来遍历分类下的所有子分类，pid是父级分类， paid=null时说明是根节点, 属于一级类别； 属性：id,pid,name等
商品表表（即spu表）：tb_product
存储商品信息。表中关键字段是category_id和attribute_list两个字段：
- category_id：记录商品属于哪个分类， 用于通过分类进行商品搜索；
- attribute_list：记录的是所有属性的集合，这个字段采用json格式存储，便于前端解析；前端解析后可以在页面显示出商品的所有属性， 用户点击选择出属性组合后，前端可以拼接成形如
{"内存":"2G","颜色":"红色","尺寸":"20cm"}的json格式加上商品id在（商品规格表 tb_product_specs）查询到具体的单品，随即获取到具体单品的库存和价格等信息； 属性：id,category_id,name,attribute_list等
商品规格表（即：sku表）：tb_product_specs
存储商品的具体规格单品，即sku。sku表保存的是具体的单品信息，比如具体规格的库存和价格等，核心字段是product_id和product_specs：
- product_id 记录的是spu表中的商品id
- product_specs 记录的是该单品具体的属性值（规格值）； 属性：id,product_id,product_specs等
属性key表：tb_attribute_key
用于存储sku的属性,比如：机身颜色，存储容量 属性key表和属性value表仅用于管理后台页面生成属性选项，管理员在发布新商品时勾选属性，方便规格的录入和保证正确性；
属性value表：tb_attribute_value
用于存储sku的属性值,比如：6+128G，8+128G，8+256G
总结
上述数据表设计方案适用于商品类别差异不是很大的情形，通过表的字段可以发现不同的商品之间变化的信息只有 attribute_list 字段， 而这个字段通过json来存储各种不同的属性集合， 同样sku表中变化的字段只有 product_specs 也是通过json来存储各种不同属性组合。
