如上图是我们常见的商超或者便利店中看到的货架形式.如图中的各式各样的瓷碗,不同颜色,不同大小一一陈列,每个商品都直接与用户建立连接.大小,颜色,种类的信息这样直接展示给用户.
相比之下线上的售卖场景,货品的展示不同于线下售卖的场景,如下图中我们在展示瓷碗时,将通过
多规格场景主要用于线上电商系统.实现线上场景售卖过程中不同规格组合进行售卖.如下.
Standard Product Unit(标准化产品单元),一种商品,各种规格集合,如:RedMi K50;
Stock Keeping Unit(库存量单位),也称单品,一种商品的具体规格,如:一部 雅黑 8G+128G 的RedMi K50手机.规格项颜色#版本#购买方式 就是商品的具体规格项.规格值颜色=>雅黑.版本=> 8G+128G 就是商品的具体规格值
单规格就是当每个商品仅只有一个规格项.如:盘锦大米 5kg. 仅有重量规格项.多规格如上RedMi K50.从系统扩展性的角度,将系统商品设计为单规格可以适配后期如果有多规格的产品业务场景.
如上图中所述.从服务的角度做了一个简单的梳理.我们从整个商品系统的全貌了解下目前的一些服务结构信息.
书不尽言,后续我们将从具体的一些场景实例来详尽介绍遇到的一些场景以及设计方案.持续更新中.
上图是单规格版也就是sku和spu存在的一对一的情况,从系统的设计就没有必要从db角度做一个拆分.
只用处理商品与店品的关系,相对来说比较简单.
如上图是我们在整个系统持续演进之后,增加了多规格的设计.顾名思义这时候我们不得不重新梳理spu与sku的关系,换句话说这时候我们才会去考虑spu和sku之间的区别,标品服务信息管理与库存管理单元的关系.以及门店商品这时候仅关联的则是sku的关联.这是商品维度.
相比单规格模式下,多规格服务最大的莫过于就是增加多规格的概念.从规格的管理,到规格与sku关系的映射.其中最为复杂则就是规格项,规格值交叉后的具体规格品的信息处理.下述将介绍.
如下为上述ER关键数据库设计,并不涉及详细的DB设计.仅为关键字段设计.骨架的设计.具体的产品业务将可以在此基础上继续扩展设计.
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 表同种规格的标准单元,集中了公共的属性字段.如:类目,品牌,名称,详描,产地,广告词,售卖方式(计件品,称重品,)
使用场景:保存了库存维度的商品信息处理
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主表'
使用场景:当使用商家存在多个线上店铺时,并且在多个店铺上商品的信息存在区域性差异.如.如下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主表'
使用场景:用以保存诸如颜色,尺码,大小.
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='规格组表'
使用场景:用以保存规格项的具体值.诸如 颜色下的:黄色 红色 白色 黑色.
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='规格值表'
使用场景:用以保存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和规格值关联表'
使用场景用以固定规格项在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规格排序关系表'
如上图为主档建品后下发门店商品流程.关键点
如 颜色=黄色; 大小=大; 尺码=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的生产以及管理.这是我的设计.欢迎一起讨论,交流
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。