为什么创立新专栏

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

前言

本篇是以以往我在思否公布的三篇《电商零碎设计之商品（上中下）》汇总的一篇联合我这些年经验的升级版，在文字描述与流程图上更标准，这里也贴上以往的三篇文章链接。

• 电商零碎设计之商品 (上) https://segmentfault.com/a/11…
• 电商零碎设计之商品 (中) https://segmentfault.com/a/11…
• 电商零碎设计之商品 (下) https://segmentfault.com/a/11…

商品的设计是电商零碎中占据重要位置，如何设计出高扩大，高性能的商品零碎并非一件简略的事件，我的设计是参考互联网各大佬的设计后自行钻研的，并非完全正确，但也不齐全谬误，当初我设计的这套电商零碎曾经在应用，如果在逻辑上遇到什么问题，会及时批改我对于电商零碎相干文章的设计思维局部。

根本思维

见上图，咱们先解说下零碎规格与自定义规格、零碎属性与自定义属性的对于及其他们存在的意义。

SPU

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

什么叫标准化产品单元？

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

例如 iphonex 的价格也不同的中央，别离为 iphonex 64g 是 8888,iphonex 256g 是 18888。这个时候咱们不能建设 2 个 spu 去治理这 2 个商品。这个时候就须要用到 spu 的概念了。

SKU

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 的产品，失常状况下订单表应该与此 SKU 编码相关联来维持数据一致性。像这样

这种设计有个弊病，商品的名称及价格都不是固定，如果商户批改了商品的题目或者其余的属性，那小明过后买的爱疯手机是 8000 元，后果过了几年提价了商户批改了价格，后果小明的购买清单里也变成了批改后的价格，所以说这种仅仅关联的设计是不可取的(至多在电商零碎中不可取)。

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

我的答复是“保持数据关联”，尽管商户有可能扭转商品属性，但应该尽可能的记录用户所有的动作。

多商户电商

理论在电商零碎设计上，个人感觉不应辨别多商户的电商与单用户的电商(至多开发者不应辨别他们)，但后期设计上就应把多商户概念带入到零碎内。哪怕只有一个官网专卖店呢？！

波及到多商户就须要思考用户对立下单问题了。

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

对于多商户的问题不是本章的重点，本次我先提出这几个疑难, 感兴趣的同学能够提前思考下，后续文章会具体解说

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

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

订单表

订单详情表

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

后盾性能列表

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

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

相干数据表

https://github.com/CrazyCodes…

致谢

谢谢你看到这里，心愿我的文章可能帮忙到你。有什么问题能够在评论区留言，我看到会第一工夫回复。谢谢！