为什么要新建栏目创建《一文秒懂》本栏目不同于《Grace development》和我的博客。定位是一个有态度、有高标准的技术栏目，而《Grace development》我还是会说说我们在日常生活中遇到的一些技术问题，分享我的个人经验。前言本文是我以往在Thinking发表的三篇《电商系统设计之商品（上中下）》文章的升级版，结合我多年的经验。它在文字描述和流程图方面更加规范。这里还有前三篇文章的链接。电子商务系统设计中的商品（上）https://segmentfault.com/a/11...电子商务系统设计中的商品（中）https://segmentfault.com/a/11...设计在电子商务系统商品（第2部分）https://segmentfault.com/a/11...商品设计在电子商务系统中起着重要作用。如何设计一个高扩展性、高性能的商品系统并不是一件简单的事情。I本网站的设计参考了互联网巨头的设计。不完全正确，但也不完全错误。现在我设计的电子商务系统已经投入使用了。如果有逻辑上的问题，我会及时修改。我关于电子商务系统的文章的设计思维部分。基本思路如上图所示。先解释一下系统规范和自定义规范、系统属性和自定义属性的关系，以及它们存在的意义。SPUSPU(StandardProductUnit)什么是标准化产品单元？放弃标准化、产品单元这个术语？就是以一个产品为单位。比如你是卖笔记本的，厂家进货的时候说要100个型号的iphonex，规格随机，你进货的时候没有考虑内存和屏幕大小。这时候你就把产品iphonex当成了一个单位。这是产品单位。再说标准化，就是这样一个人或一个人制定的标准，所以叫标准化产品单元。不要用百度百科上的解释来反驳我。我只是用一种更容易理解的方式来解释SPU。比如iphonex的价格也不一样，iphonex64g是8888，iphonex256g是18888。这时候我们不能创建2个SPU来管理这2个商品。这时候就需要用到spu的概念。SKUSKU(StockKeepingUnit)什么是库存单位？从字面上理解，库存是指某种产品的某种规格还剩多少件。这时，它不能只针对产品。在上面的例子中，iphonex有2款不同规格的产品。这个时候不可能统计每个规格的库存（创建2个产品不切实际，以后管理会很复杂，比如安踏的跑鞋就有十几个尺码，可以吗？想创建十几个产品？），此时只能为当前产品创建子产品，我们称之为规格，例如iphonex有存储和颜色两个规格，你找到了吗？有问题吗？具体存储大小和具体颜色如何表达？这时候就需要创建一个规格的子产品。我们称之为属性。每个属性的组合就是一个新产品。我们称之为SKU。一个SPU对应N个SKU，所以生成N个产品iphonex64Gwhiteiphonex32Gblackiphonex256Gwhite等等...systemspecification/property为什么要设置systemspecificationproperty？淘宝盗图，以上规格和属性是按照分类品牌设置的，主要是为了方便商家添加商品，统一管理商品的规格和属性。当然，电子商务系统处于运营初期。尽量少用系统属性规范（方便商户打卡）。自定义属性就不用说了，怎么可能不允许商家自己添加规格尺寸呢？SPU与SKU的关系SPU对应多个SKU。SPU其实就是主品表，类似于iphonex手机，而SKU就是这个产品绑定的规格表，类似于iphonex红款，iphonex黑款等，主表和规格表也是有关联的与其他表品相册。在淘宝的逻辑中，商家可以给商品添加视频和图片，也可以给每个sku添??加图片。我们称之为专辑。将一组图片和视频绑定到产品表和sku表上的相关品牌，就像歌手和作家的专辑一样，每个产品都属于一个品牌。比如iphonex是苹果的，小米8是小米的。品牌不需要和SKU关联，原因很简单，现在的SKU是苹果的，iPhoneX以下的规格都是苹果的。绑定类别有时一个品牌并不只属于一个类别。我们以iphonex为例。它是一部手机，也是一款苹果产品，同时也是一款音乐播放器。注意此时不要将当前品牌绑定到三个类别。如果你这样做，以后的可维护性会很低。每个类别应绑定相同的品牌名称。你肯定要问了，这样不会产生数据垃圾吗？我没有具体数据可以向您展示这样做的好处。但是从业务的角度来说，现在我需要统计每个品类下的产品购买次数，来做用户画像。你如何区分当前产品属于哪个类别？无法区分，因为你把品牌绑定了三个品类，我不知道用户是通过哪个品类点击购买的。另外，很多品牌公司不仅做产品，像索尼做mp3，还做电视、手机、游戏机等等。所以，一个品类对应多个品牌，一个品牌应该对应多个品类，而不是链接多个品类。环节分析商品系统和订单系统相辅相成。买家购买一件商品时，会经过一个流程商品系统->订单系统->交易系统->订单系统->物流系统->售后系统完成以上流程即完成一笔交易。经常网购的童鞋都知道这一点。今天我们就来聊一聊从商品系统到交易系统、订单系统的存储过程及其设计中应该注意的“坑”。相关问题现在有这样一个场景，小明在某宝买了一个iCrazy手机，颜色是红色，内存是32G。他选择用某宝来支付。疯狂手机黑32G004爱疯狂手机黑256G小明选择购买SKU=001的产品。通常情况下，订单表应该与这个SKU编码关联起来，以保持数据的一致性。订单号用户SKUSN110小明001的设计有一个缺点。产品的名称和价格不固定。如果商家修改了商品的标题或其他属性，则小明以8000元购买了iCrazy手机。经过几年的降价，商家修改了价格，结果小明的购买清单也变成了修改后的价格，所以这种只关联的设计是不可取的（至少在电商中不行）系统）。订单号用户SKU商品名称商品价格商品封面图片商品其他属性SN110小明001爱狂手机8000iphone.png其他属性设计如上表，有人会问“联想是什么意思？”我的回答是“KeepDataassociation”，虽然商家可能会改变产品属性，但他们应该尽可能记录所有用户行为。多商户电商其实在电商系统的设计上，我个人觉得不应该区分多商户电商和单用户电商（至少开发者不应该区分他们），但是多商户的概念应该被引入到系统的早期设计中。即使只有一家官方商店？！当涉及多个商户时，需要考虑用户统一下单的问题。购物车下单，多个商品来自多个商家。如果分单，如何下单，通知多商户等等，多商户的问题不是本章的重点。这次先提出这几点。一个问题，有兴趣的同学可以提前想一想，后续文章会详细说明，购物车下单，多个商品来自多个商家。如果订单来自多个商家，那么订单的数据库接口应该是这样的设计订单表订单号用户SN110小明订单详情表订单号SKU用户商户SN110001小明官方SN110002小明第三方无论购买多少产品以及该商品属于多少商户，我们应该将用户一次购买的商品归于一个订单。订单下关联多个商品详情。在售后操作中，也方便买家退换单品。后台功能列表这里提供以下功能名称和URL作为参考菜单名称URL产品管理/产品发布产品/产品/创建产品类别/产品/类别品牌管理/产品/品牌规格管理/产品/属性回收站/产品/回收订单列表/订单后台的设计和操作套路我会单独写一篇介绍。这里只是一张粗略的表格。相关数据表https://github.com/CrazyCodes...致谢感谢您阅读这里，希望我的文章能对您有所帮助。有什么问题可以在评论区留言，我看到会第一时间回复。谢谢！
