最近事情有点多，所以系列文章已停止好多天了。今天我们继续Springboot电商项目实战系列文章。到目前为止，整个项目的架构和基础服务已经全部实现，分布式锁也已经讲过了。那么，现在应该到数据库设计及代码实现阶段，我们要注意或准备什么呢？今天先说说商品的数据库表设计问题吧。
image
来看看上面的图片，这个商品的数据库表怎么设计呢？是不是有人会说，4张表搞定：商品分类表、商品信息表、价格表、属性表。
image
没错，这样是可以实现，但存在很多弊端，比如就针对上面的商品（手机），不同的颜色，不同的版本都有不同的价格。按传统的设计思路，我们把版本作为属性，不同的属性对应不同的价格，看似不错。那颜色又怎么处理呢？是不是不同的版本不同的价格，颜色你就可以随便选呢？但现实中并不是这样，同一个版本配置，不同颜色往往都是不同的价格。这又怎么办呢？你可能又会说我把颜色再设置成一个属性，颜色和版本两个属性组合设置一条价格信息。那如果还有套餐呢？我们继续这样搞，是的，完全没问题。那库存呢？是否还要放在商品信息表呢？明显这样是有问题的。比如荣耀20 版本6G 128G 蓝水翡翠 已经卖完了，但这个版本的其他颜色还有货呀。那数据库到底怎么设计呢？这就是今天要讲的话题。目前的主流解决方案SPU、SKU。
商品的SPU, SKU实现
首先，什么是SPU,SKU呢？
SPU（Standard Product Unit）即标准化产品单元 SPU是商品信息聚合的最小单位，是一组可复用标准化信息的集合。
SKU（Stock Keeping Unit）即库存量单位 SKU即库存进出计量的单位，可以是以件、盒、托盘等为单位。
对于电商而言，SPU有一个唯一编码，一个SPU代表一个产品；SKU为一个产品不同属性、规格之间的编码。也就是说，SPU代表产品，SKU代表属性与规格；一个产品，可以是单属性产品，也可以是多属性产品，也就是说一个产品可以有一个SKU，也可以有多个SKU。
那么，针对上面的商品，数据库表究竟怎么设计呢？
image
这里是简单的商品SPU、SKU表设计实现，一共包含六个表。
1，商品分类表
此表添加了parent_id字段，可实现无限层级的树状数据结构，parent_id=0表明当前为根节点，否则可使用递归算法来遍历分类下的所有子分类。这里我根据上面图片中的商品添加了他的基础分类数据如下：
image
2，商品品牌表
此表的结构比较简单，就是品牌的基础信息。如图片中的荣耀手机，那么荣耀作为一个手机品牌，添加基础数据如下：
image
3，商品表（SPU）
这个表里的每一条数据就是一个标准的产品单元，也就是所谓的SPU。比如荣耀20手机，这就是一个标准的商品，所以我们把它作为一条商品数据存储。此表必须要包含的字段：商品分类ID，商品品牌ID。注：此表里的商品详情信息字段，不要直接保存商品的图文化信息，可以把图文化信息转成html静态文件存储在文件服务器，然后将存储的路径url保存在数据库此字段里。这样会在很大程度上节约数据库开销。
image
4，规格表（SKU）
规则表就是这里所谓的商品SKU实现，也就是说这里实现的是商品的存储单元。针对每一个多属性的商品，几个不同属性的组合将有自己独立的库存和价格信息。如上面的荣耀20手机，通过颜色和版本这两个属性，组成了以下6条SKU信息。
image
5，商品属性key和属性value
这两个表作为商品分类的不同属性存储，在系统开始运营就需要做数据的初始化。日后运营人员如果要新增某一商品的SKU信息，就可直接根据数据库的这些基础数据选取，然后将属性再以json的形式存储到对应的规格表。
属性key:
image
属性value：
image
好了，到此为止商品的SPU、SKU已经说完了。今天我讲的这个设计方案，可完全适用于商品类别差异化不大的项目或系统中。但针对差异化较大的情况，那就需要根据自己的业务情况去优化处理。
注：此SpringBoot电商实战项目的源码已上传到github上并已开源，有需要的可以扫码关注公众号，然后发送“Springboot”获取github地址。
扫码关注公众号，发送关键词获取相关资料：
- 发送“Springboot”领取电商项目实战源码；
- 发送“SpringCloud”领取cloud学习实战资料；
image
网友评论