SpringBoot电商项目实战 — 商品的SPU/SKU实现

最近事情有点多,所以系列文章已停止好多天了。今天我们继续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地址。

扫码关注公众号,发送关键词获取相关资料:

  1. 发送“Springboot”领取电商项目实战源码;
  2. 发送“SpringCloud”领取cloud学习实战资料;
 
posted @ 2019-08-23 12:25  码农大哥  阅读(2519)  评论(0编辑  收藏  举报