为什么创建新专栏

创建《一文秒懂》这个专栏与以往《Grace development》和我博客的个人分享文章不同，我对《一文秒懂》这个专栏的定位是一个有态度，高标准的技术专栏，而《Grace development》我依旧会讲一些我们日常中会碰到的一些技术问题及我个人的经验分享。

本篇是以以往我在思否发布的三篇《电商系统设计之商品（上中下）》汇总的一篇结合我这些年经历的升级版，在文字描述与流程图上更规范，这里也贴上以往的三篇文章链接。

商品的设计是电商系统中占据重要地位，如何设计出高扩展，高性能的商品系统并非一件简单的事情，我的设计是参考互联网各大佬的设计后自行研究的，并非完全正确，但也不完全错误，现在我设计的这套电商系统已经在使用，如果在逻辑上遇到什么问题，会及时修改我关于电商系统相关文章的设计思想部分。

见上图，我们先讲解下系统规格与自定义规格、系统属性与自定义属性的关于及其他们存在的意义。

SPU(Standard Product Unit)标准化产品单元

什么叫标准化产品单元？

抛弃标准化一词来看，产品单元？就是以一个产品为一个单位。例如你是手记销售商，你在厂家进货的时候说我要iphonex 100部型号随意规格随意，进货的时候没考虑到内存或者屏幕尺寸，这个时候你就把iphonex这个商品当作一个单位。这就是产品单位。再谈标准化，只是一些人或一个人制定的这么一个标准，所以称为标准化产品单元，不要拿百度百科上的解释反驳我，我只是用更通俗易懂的方式解释一下SPU。

例如iphonex的价格也不同的地方，分别为iphonex 64g 是8888,iphonex 256g是18888。这个时候我们不能建立2个spu去管理这2个商品。这个时候就需要用到spu的概念了。

SKU(Stock Keeping Unit)库存量单元

什么叫库存量单位?

字面意思来看，库存则是指的某个商品的某个规格还有多少件，这个时候就不能只针对商品了。上面的例子iphonex有2个不同规格的商品，这个时候无法计算其每个规格的库存(创建2个商品可是不切实际，未来管理会很复杂，就例如安踏的跑鞋有十几个尺码，难道要创建十几个商品吗？),此时只能针对当前商品再创建子商品，我们叫它规格，例如iphonex有存储和颜色2个规格

有木有发现还是有点问题？那具体的存储大小与具体颜色该如何表达呢？这个时候需要创建规格的子商品，我们称他为属性

这个每个属性的结合则就是一个新的商品，我们称它为SKU，一个SPU对应着N个SKU

这样就生成了N个商品

iphonex 64G白色
iphonex 32G黑色
iphonex 256G白色 等等...

系统规格/属性

为什么要设立系统规格属性呢？

盗用一张淘宝的图，以上都是根据分类品牌设定好的规格及属性

主要是为了方便商家添加商品及其对商品的规格属性进行统一的管理，当然一个电商系统在前期运营的情况下尽量减少系统属性规格的使用（方便商家入住嘛）。

自定义属性就不用说了，不让商家添加自己的规格和尺码什么的怎么能行？

SPU与SKU的关联

SPU对应多个SKU,SPU实际就是主商品表，类似于iphonex这款手机，而SKU则是这个商品绑定的规格表，类似与iphonex 红色款,iphonex 黑色款等。

而主表与规格表也关联了其他表

在淘宝的逻辑中,商家可为商品添加视频和图片，可为每个sku添加图片。我们称为专辑。将一组图片及视频类似歌手作家出专辑一样，绑定到商品表和sku表上

每个商品都归属与一个品牌，例如iphonex归属与苹果公司,小米8归属与小米公司一样。品牌无需关联到sku内，道理很简单，当前的sku是iphonex归属与苹果公司，自然而然iphonex下面的规格都属于苹果了。

有时品牌不仅仅归属与一个类目，还是以iphonex举例，他是一部手机又是苹果产品但他又是一个音乐播放器。注意，这个时候不要将当前品牌绑定到三个类目上，如果你这样做了，未来的可维护性会很低。应该每个类目中绑定相同的品牌名称，你一定会问那这样数据垃圾不就产生了吗？我没有具体数据给你展现这样做的好处。

但从业务说起，现在我需要统计每个类目下商品的购买数去做用户画像，你时你要如何区分当前这个商品到底是哪个类目下呢？无法区分，因为你将品牌绑定到了3个类目下，不知用户到底是通过哪个类目点击进去购买的。

再者很多品牌公司不仅仅是做一个商品，类似索尼做mp3也做电视，手机，游戏机等。所以类目对应多个品牌，品牌应对应多个类目并非关联多个类目

商品系统与订单系统是相铺相成的，当买家购买商品后将经历一个过程

商品系统->订单系统->交易系统->订单系统->物流系统->售后系统

完成上述流程则是完成了一笔交易,经常网上购物的童鞋都懂这个。今天我们讲下从商品系统到交易系统和订单系统的存储过程及其设计上的应该注意的“坑”。

现在有这么一个场景

小明在某宝买了一部爱疯手机,颜色是红色,存储是32G，他选择使用某宝支付.

SKU产品颜色存储001爱疯手机红色32G002爱疯手机红色256G003爱疯手机黑色32G004爱疯手机黑色256G

小明选择购买SKU=001的产品，正常情况下订单表应该与此SKU编码相关联来维持数据一致性。像这样

订单号用户SKUSN110小明001

这种设计有个弊端，商品的名称及价格都不是固定，如果商户修改了商品的标题或者其他的属性，那小明当时买的爱疯手机是8000元，结果过了几年降价了商户修改了价格，结果小明的购买清单里也变成了修改后的价格，所以说这种仅仅关联的设计是不可取的(至少在电商系统中不可取)。

订单号用户SKU商品标题商品价格商品封面图商品其他属性SN110小明001爱疯手机8000iphone.png其他属性

像上表中设计，有人会问了 “那关联的意义何在呢？”

我的回答是 “保持数据关联” ，虽然商户有可能改变商品属性，但应该尽可能的记录用户所有的动作。

多商户电商

实际在电商系统设计上，个人感觉不应区分多商户的电商与单用户的电商(至少开发者不应区分他们)，但前期设计上就应把多商户概念带入到系统内。哪怕只有一个官方专卖店呢？！

涉及到多商户就需要考虑用户统一下单问题了。

• 订单是由购物车下单，多个商品来自多个商户
• 如果进行拆单、分单
• 如何进行下单通知等等多商户的问题

关于多商户的问题不是本章的重点，本次我先提出这几个疑问,感兴趣的同学可以提前思考下，后续文章会详细讲解

订单是由购物车下单，多个商品来自多个商户

如果下单是来自多个商户的商品，那么订单的数据库接口应该这样设计

订单表

订单号用户SN110小明

订单详情表

订单号SKU用户商户SN110001小明官方SN110002小明第三方

无论购买多少商品并且商品归属于多少个商户，我们都应把用户一次性购买的商品归属与一个订单，订单下再关联多个商品的详情。在售后操作上，也方便买家退换单个商品。

后台功能列表

这里提供下功能名称与URL为参考

菜单名称URL商品管理/product发布商品/product/create商品类目/product/category品牌管理/product/brand规格管理/product/attribute回收站/product/recycle订单列表/order

后台的设计和操作套路我会单独拿一篇文章来介绍。这里只做一个大概的table。

相关数据表

https://github.com/CrazyCodes...

谢谢你看到这里，希望我的文章能够帮助到你。有什么问题可以在评论区留言，我看到会第一时间回复。谢谢！