SaaS 电商设计 (一) 如何设计一套适应多规格的商品服务

专栏系列

-SaaS 电商设计 (一) 如何设计一套适应多规格的商品服务
-SaaS 电商设计 (二) 私有化部署-缓存中间件适配
-SaaS 电商设计 (三) 电商黄金流程(商详,购物车,提单)梳理,持续更新(建议收藏)
-SaaS 电商设计 (四) 谈一谈电商系统高并发多耦合上下游的系统压测怎么做
-SaaS 电商设计 (五) 私有化部署-实现 binlog 中间件适配(附源码)
-SaaS 电商设计 (六) 实现 id 生成器本地化生产 (附源码)
-SaaS 电商设计 (七) 利用 Spring 扩展点 ImportBeanDefinitionRegistrar 实现 toB 系统对接(附源码)

一.背景 & 名词解释

1.1 背景

如上图是我们常见的商超或者便利店中看到的货架形式.如图中的各式各样的瓷碗,不同颜色,不同大小一一陈列,每个商品都直接与用户建立连接.大小,颜色,种类的信息这样直接展示给用户.

相比之下线上的售卖场景,货品的展示不同于线下售卖的场景,如下图中我们在展示瓷碗时,将通过
多规格场景主要用于线上电商系统.实现线上场景售卖过程中不同规格组合进行售卖.如下.

1.2 名词答疑

1.2.1 什么是SPU?

Standard Product Unit（标准化产品单元），一种商品，各种规格集合，如：RedMi K50；

1.2.2 什么是SKU?

Stock Keeping Unit（库存量单位），也称单品，一种商品的具体规格，如：一部 雅黑 8G+128G 的RedMi K50手机.规格项颜色#版本#购买方式 就是商品的具体规格项.规格值颜色=>雅黑.版本=> 8G+128G 就是商品的具体规格值

1.2.3 什么是多规格?

单规格就是当每个商品仅只有一个规格项.如:盘锦大米 5kg. 仅有重量规格项.多规格如上RedMi K50.从系统扩展性的角度,将系统商品设计为单规格可以适配后期如果有多规格的产品业务场景.

二.方案设计

2.1 系统设计

如上图中所述.从服务的角度做了一个简单的梳理.我们从整个商品系统的全貌了解下目前的一些服务结构信息.
书不尽言,后续我们将从具体的一些场景实例来详尽介绍遇到的一些场景以及设计方案.持续更新中.

2.2 ER模型

2.2.1 单规格版

上图是单规格版也就是sku和spu存在的一对一的情况,从系统的设计就没有必要从db角度做一个拆分.
只用处理商品与店品的关系,相对来说比较简单.

2.2.2 多规格版

• 商品关系重新梳理
  如上图是我们在整个系统持续演进之后,增加了多规格的设计.顾名思义这时候我们不得不重新梳理spu与sku的关系,换句话说这时候我们才会去考虑spu和sku之间的区别,标品服务信息管理与库存管理单元的关系.以及门店商品这时候仅关联的则是sku的关联.这是商品维度.
• 规格概念插入
  相比单规格模式下,多规格服务最大的莫过于就是增加多规格的概念.从规格的管理,到规格与sku关系的映射.其中最为复杂则就是规格项,规格值交叉后的具体规格品的信息处理.下述将介绍.

2.3 详细设计

如下为上述ER关键数据库设计,并不涉及详细的DB设计.仅为关键字段设计.骨架的设计.具体的产品业务将可以在此基础上继续扩展设计.

2.3.1 SPU 表

CREATE TABLE `product` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
  `product_id` varchar(50) NOT NULL DEFAULT '' COMMENT '商品id',
  `category_id` bigint(20) unsigned NOT NULL COMMENT '类目id',
  `brand_id` bigint(20) unsigned DEFAULT NULL COMMENT '品牌编号',
  `brand_name` varchar(128) DEFAULT '' COMMENT '品牌name',
  `title` varchar(128) DEFAULT '' COMMENT '商品名称',
  ...
  UNIQUE KEY `uniq_productionId` (`product_id`) USING BTREE,
  KEY `idx_name` (`title`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COMMENT='商品主表'

SPU 表同种规格的标准单元,集中了公共的属性字段.如:类目,品牌,名称,详描,产地,广告词,售卖方式(计件品,称重品,)

2.3.2 SKU 表

使用场景:保存了库存维度的商品信息处理

CREATE TABLE `sku` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
  `sku_id` varchar(50) NOT NULL DEFAULT '' COMMENT 'skuId',
  `sku_name` varchar(256) NOT NULL DEFAULT '' COMMENT 'sku名称',
  `product_id` varchar(50) NOT NULL DEFAULT '' COMMENT '商品id',
  `validate_id` varchar(256) NOT NULL DEFAULT '' COMMENT '校验id.for规格项顺序调整后不会重复生产SKU',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uniq_skuId` (`sku_id`) USING BTREE,
  UNIQUE KEY `uniq_validateId` (`validate_id`) USING BTREE,
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COMMENT='sku主表'

2.3.3 store_sku 表

使用场景:当使用商家存在多个线上店铺时,并且在多个店铺上商品的信息存在区域性差异.如.如下store_sku表为主档商品下发到店铺级别的设计.

CREATE TABLE `store_sku` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  `store_id` bigint(20) NOT NULL COMMENT '门店id',
  `sku_id` varchar(50) NOT NULL COMMENT 'skuId',
  `base_price` decimal(20,2) DEFAULT NULL COMMENT '价格',
  `product_id` varchar(50) NOT NULL COMMENT '商品Id',
  `sku_name` varchar(256) DEFAULT NULL COMMENT 'sku名称',
  `sku_short_name` varchar(64) DEFAULT NULL COMMENT 'sku简称',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uniq_storeId_skuId` (`store_id`,`sku_id`) USING BTREE,
  KEY `idx_productId` (`product_id`),
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COMMENT='门店SKU主表'

2.3.4 规格组表

使用场景:用以保存诸如颜色,尺码,大小.

CREATE TABLE `spec_group` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键',
  `spec_group_id` bigint(20) NOT NULL COMMENT '规格id',
  `spec_group_name` varchar(64) NOT NULL COMMENT '规格名称',
  `order_sort` int(11) NOT NULL COMMENT '排序',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uniq_specGroupId` (`spec_group_id`) USING BTREE
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COMMENT='规格组表'

2.3.5 规格值表

使用场景:用以保存规格项的具体值.诸如 颜色下的:黄色 红色 白色 黑色.

CREATE TABLE `spec_value` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键',
  `spec_group_id` bigint(20) NOT NULL COMMENT '规格id',
  `spec_value_id` bigint(20) NOT NULL COMMENT '规格值id',
  `spec_value` varchar(64) NOT NULL COMMENT '规格值',
  `order_sort` int(11) NOT NULL COMMENT '排序',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uniq_specGroupId_specValueId` (`spec_group_id`,`spec_value_id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='规格值表'

2.3.6 规格值sku关联表

使用场景:用以保存sku关联的规格项以及规格值.

CREATE TABLE `sku_spec_value_relation` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键',
  `product_id` varchar(20) NOT NULL COMMENT 'SPUID',
  `sku_id` varchar(20) NOT NULL COMMENT 'skuID',
  `spec_group_id` bigint(20) NOT NULL COMMENT '规格id',
  `spec_group_name` varchar(64) DEFAULT NULL COMMENT '规格名称',
  `spec_value_id` bigint(20) NOT NULL COMMENT '规格值id',
  `spec_value` varchar(64) DEFAULT NULL COMMENT '规格值',
  `spec_value_sort` int(11) DEFAULT NULL COMMENT '规格值排序',
  PRIMARY KEY (`id`),
  KEY `idx_productId_skuId` (`product_id`,`sku_id`),
  KEY `idx_productId_specId` (`product_id`,`spec_group_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='sku和规格值关联表'

2.3.7 规格项spu关联表

使用场景用以固定规格项在toC端展示的顺序.如:颜色 大小 尺码的顺序.需要调整为大小 尺码 颜色,将通过此表冗余sort处理.本身可以以上的表结构设计来做到处理,考虑到逻辑处理起来比较清晰还是单独做了一份冗余处理.如下为关键字段设计.

CREATE TABLE `spu_spec_sort_relation` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键',
  `product_id` varchar(20) NOT NULL COMMENT 'SPUID',
  `spec_group_id` bigint(20) NOT NULL COMMENT '规格id',
  `spec_group_name` varchar(64) DEFAULT NULL COMMENT '规格名称',
  `spec_sort` int(11) DEFAULT NULL COMMENT '规格排序',
  PRIMARY KEY (`id`),
  KEY `idx_productId_specgpId` (`product_id`,`spec_group_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='spu规格排序关系表'

2.4 建品流程

如上图为主档建品后下发门店商品流程.关键点

• 销售门店设置
• 规格值验重判断如下2.5.1 详细介绍

2.5 多规格关键技术点

2.5.1 规格项乱序后解决重复生产sku场景

• 场景:
  如 颜色=黄色; 大小=大; 尺码=L码. 在调整顺序后大小=大; 尺码=L码; 颜色=黄色 不会重复生产Sku因为从页面上来看是同一个SKU.仅仅调整的规格项的顺序.
• 方案:
  新增sku时：sku表冗余当前sku关联的规格属性 根据规格和规格值的主键排序，根据spuid，规格id和规格值id拼成唯一的值;如:productId 100001, specValueId 1, specValueId 12,==> 校验repeatId:100001_01_12.更新商品时：根据sku重新绑定的规格和规格值，去规格和规格值表查询相应的排序，根据spuid，规格id和规格值id拼成唯一的值，从而比较新增时生成的值是否一致，来判别新增或更新操作.

三.总结

综上,其实相比来说最为核心的还是规格这块的设计.保证了具体sku的生产以及管理.这是我的设计.欢迎一起讨论,交流