谈谈电商系统中的商品模块设计
电商系统基本是开发者接触的最多的系统了，对于一个电商系统，商品模块显然是其核心功能，商品模块设计的好坏直接决定后续的开发进度和维护成本。
sku与spu
sku 和 spu 是用来描述商品的结构，所以我们想要设计一个好的商品模块需要先了解这两个概念
spu
SPU = Standard Product Unit (标准化产品单元)
SPU是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息的集合，该集合描述了一个产品的特性。即产品单元。
白话：你发工资了，想整台 iphone 11，这个时候 iphone 11 就是 spu ，是一组可复用、易检索的标准化信息的集合， iphone 11 就包含了 内存、颜色、版本，等信息，是他们的这些可复用信息的集合。 spu 就是某个产品，但是我们去购买产品，是需要具体的规格属性的，我们真正购买的 库存单元-sku
sku
SKU = Stock Keeping Unit （库存量单位）
SKU即库存进出计量的单位， 可以是以件、盒、托盘等为单位。SKU是物理上不可分割的最小存货单元。在使用时要根据不同业态，不同管理模式来处理。
白话：上面我们说到要整一个 iphone 11，但是吧，我们去商店购买的时候营业员肯定是会问我们需要一个啥样的 iphone 11？啥颜色？啥内存？啥版本？ 红色-128G-国行 可以形容一个具体的产品，这些属性的组合即是我们的 sku，我们最终购买也是 sku ，商家去进货也是进具体的款式，所以我们的库存是跟 sku 挂钩的，而不是直接和产品挂钩。
商品基础数据库相关设计
我们需要将上面的概念抽象进行数据库设计。我们是需要将以下的关联数据存储到数据库
基于以上规则，我们设计商品的基础数据表
表说明
- product 商品基础表
keyword 用于做搜索的关键词 warning_stock 用于做库存预警
- product_sku 商品sku表
我们采用 data 字段以 json 格式进行存储，存储格式可以为
[ ["id" => 1, "value" => "套餐一"], ["id" => 2, "value" => "土豪金"], ["id" => 3, "value" => "256G"], ]
像以前我们会用一个单独的 varchar 字段，属性值以某种符合进行连接处理，例如：1_2_3 , 标识 套餐一 土豪金 256G，对于 json 格式的存储这种缺点也显而易见，有时候不需要一味地追求数据库设计范式，特别是 Mysql 加入 JSON 支持之后，只要不涉及到搜索查询的都可以往 JSON 字段里丢。
- product_detail 商品详情
商品的详情属于存储字符比较多，所以单独处理，也可以利用这个表扩展相关商品描述字段
- product_spec 商品规格表
- product_spec_item 商品属性表
如何根据业务做出合适的商品模块？
上面数据表只是设计的最基础的商品的存储，如果我们要设计出好的模块，先要确定几个点:
- 平台还是自营
- 现在和未来经营的类目是标品还是非标品
- 公司经营的商品种类
- 是否有分仓发货业务，库存是否要绑定
电商自营和电商平台的区别
电商自营，意味着所有的 item 和 sku 都是由己方的运营控制，供货商也稳定为自营的一家，所以从常规意义上来说，电商平台一定需要 SPU 的模块，而自营电商不一定需要 SPU 模块，例如某东。
SPU 主要是用来解决相同商品多 item 的规格和描述信息统一的问题，并且方便运营做整个平台的商品管理。后期的实际业务中，如果平台运营走的是类似天猫这样对商家控制比较严格的路子，商家在进行商品管理，也需要对商品可操作的 SPU 进行授权管理，以及分润比例控制。这些都是可以基于 SPU 进行的。
经营类目是标品还是非标品
如果加入了 SPU 的模块，则需要了解经营类目是标品还是非标品。如果是标品，则可以在 SPU 层面加入 SPU 模版，以达到进一步对商家可能发布的 SKU 的控制，确保平台的商品可靠性。例：已知 iPhone X 只有 银色64G、银色256G、灰色64G、灰色256G这四种规格，那么平台是可以在设置 iPhone X 的 SPU 时，直接设置好 iPhone X 下的这四个规格的属性。这样商家在创建时可以直接结用这四个属性的信息进行商品创建，规范了平台商品的同时也达到了减少商家工作量的目的。
公司经营的商品种类
这个一般不会对 SPU 和 SKU 的结构关系造成影响，但是也是我们前期需要考虑的点。因为不同的商品种类可能会对之后的交易订单履约流程造成影响。简要归纳商品种类包含如下：
- 实物商品服务（打车，团购）
- 虚拟资产（话费，游戏币）
- 信息（卡密、简历、数据）
一般电商平台我们常见的商品种类主要还是实物商品和虚拟资产，而服务类商品多见于线下 O2O 项目，信息类产品大多是垂直领域。所以如果可能涉及到多种类的商品交易，则需要在设计 SPU 或 item 时就考虑到商品种类的设置。如果是在现有的系统基础上去新增商品类型，其实也可以通过指定后台类目商品类型的方式进行后续的订单履约业务。
是否有分仓
发货业务，库存是否要绑定同样的，这个业务也不会影响 SPU 和 SKU 的结构关系，但是在设计中也是很重要的点。如果有分仓发货业务，则需要考虑以下几个要点：
- 仓与仓之间是否具备跨仓发货的条件
导致这个问题的可能性有很多，如成本高，距离过远则物流质量无法保证等。
如果不具备跨仓发货条件，那可能需要根据实际业务来对每个分仓设置其所配送区域范围（根据业务需求可以精确到省/市/区县/街道），再对上架 SKU 设置其在不同分仓的库存，或者自动同步仓库库存。而前台则需要用户确认自己所在的城市或收货区域，以用来查询上架 SKU 的库存情况，确认是否能加入购物车或是下单。
- 是否有商品具备特殊的配送范围
比如，分仓常规商品可以配送北上广。但是澳洲龙虾的生命力不如波士顿龙虾，只能在分仓同城配送。这种情况下，配送范围就不能跟着仓库走，而应该跟着商品走。商品可以默认配送范围就是分仓的配送范围，但是也可以完全自定义。
- 实际运营业务中针对分仓的商品售卖是否会有价格差异。
比如波士顿龙虾的货物到岗清关是在上海，而针对波龙的销售除了江浙沪外，还有珠三角的业务，这时候需要将在上海清关的波龙在通过冷链干线运送到珠三角的水产仓/放养池。
那这部分珠三角和长三角的成本差异自然也会提现在最终售价里，从而变为同样的 SKU 由于销售城市的不同售价不同的情况。如果出现这种情况，而运营又对精细化控制有要求的话，可能 SKU 的售价控制，就需要精确到市了。
我们展示商品是展示sku还是spu？
我们可以看到京东或者淘宝的商品，京东和淘宝的展示的商品还不太一样，他们的展示方式都有不同的原因，我们来分析一下：
- 第一点：京东的商品以展示单品为主，而淘宝以展示店铺为主。
- 第二点：京东前台以
SKU为主，淘宝前台是以SPU为主。 - 第三点：京东标题讲究精准搜索，淘宝标题则更多人选择的是关键词堆积用满30个字
所以我们需要展示 sku 还是 spu ，可以根据我们产品的方向进行选择，不用盲目的进行模仿。
