word网站超链接怎么做成都购物网站设计

word网站超链接怎么做,成都购物网站设计,手机之家官网首页,数码科技网站商品系统是电子商务的核心系统之一#xff0c;是各种电商业务展开的基础和起点#xff0c;没有调查就没有发言权#xff0c;个人也深度参与设计开发和维护过商品系统#xff0c;本文简单分享下PowerDotNet重写过的商品平台系统。 十多年前我刚入行#xff0c;首次接触电商…商品系统是电子商务的核心系统之一是各种电商业务展开的基础和起点没有调查就没有发言权个人也深度参与设计开发和维护过商品系统本文简单分享下PowerDotNet重写过的商品平台系统。十多年前我刚入行首次接触电商业务系统开发开发重点集中在财务、库管、订单等这些需要后台强力支持的系统反而对商品有个刻板印象就是觉得商品系统简单字典型应用而已难度不大。随着开发和填坑经验的累积以及业务知识面的扩大从传统B2C到OTA到酒店到在线阅读再到生鲜电商一路走来当我真正独立设计实现过一次商品系统才深刻意识到当初对商品的想法相当浅薄。商品作为电商业务基础主数据在中小公司可以抽象到基础数据平台中管理个人工作过的公司就有这样处理的不过大中型公司通常都会独立开发商品管理系统(CMS)充分说明商品管理的重要性。PowerDotNet的商品平台Power.Commodity目前已经重写完成有时写的很挣扎这可能和个人追求完美要从良好到更好再到更加好的自我要求有关更可能是间隔过长看不懂自己的祖传代码^_-。想起代码大全里的话大意是需求和设计文档都可能过时而源代码往往是对软件的唯一精准描述很多项目程序员可以唯一得到的文档就是源代码本身。深度分析过祖传代码就能理解这话真是至理。在实现商品系统的过程中我也跟风热血沸腾激情澎湃用上了如日中天的AI工具比如Cursor、Copilot、通义千问和DeepSeek等人工智能果然厉害因为我真有一堆祖传商品代码需要和AI交叉验证。没有代码支撑的系统设计无异于镜花水月空中楼阁可行性、可用性和稳定性都很可疑Power.Commodity则建立在我个人实际工作过的商品系统代码基础之上至少设计和实现都经受过生产环境考验。商品系统建模相对还是比较简单的但面对复杂的业务场景为了满足业务需要不得不做出设计上的妥协这种其实就是个性化需求个人经历过的很多个性化商品需求在Power.Commodity都没有实现。相对于传统的商品个人也先后参与过服务商品、虚拟商品、汽车商品和生鲜商品的设计开发和维护工作这四类商品有其不言而喻的特殊性和复杂度一言以蔽之通用性不足本文只做一些概要说明。本文介绍的商品只是个人经验中最经典和传统的商品模型特殊商品我热血沸腾激情澎湃写了几周都不太满意就撤销了很多代码工作量实在巨大尽管如此依然符合我们先写出来再说出来的务实风格。环境准备1、必须.Net Framework4.52、必须关系型数据库MySQL或SqlServer或PostgreSQL或MariaDB四选一3、必须PowerDotNet数据库管理平台4、必须PowerDotNet配置中心Power.ConfigCenter5、必须PowerDotNet注册中心Power.RegistryCenter6、必须PowerDotNet缓存平台Power.Cache7、必须PowerDotNet消息平台Power.Message8、必须PowerDotNet文件平台Power.File9、必须PowerDotNet人员管理平台Power.HCRM10、必须PowerDotNet基础数据平台Power.BaseData一、名词术语商品可以认为是影响传统电商业务全局的基础数据在供应链、仓库、门店、订单、支付、财务、结算、配送等业务端被广泛使用对电商业务正常运营流转有举足轻重的作用。所有的辩论都是定义之争。作为给电商中的商品、渠道商品和货品都写过代码的资深开发个人很熟悉不良商品设计给仓端、配端和财务等系统造成的问题觉得有必要再明确商品的定义。商品特别基础但有些公司直到倒闭了对商品概念还含糊不清别问我怎么知道的我就是知道咩哈哈。本着发现问题定义问题解决问题的原则本文争取把商品管理写个清楚明白。职业生涯至今有了些业务和技术积累但在商品管理里经常碰到误把冯京作马凉的情况反而是看上去盘根错节枝繁叶茂的支付、财务和CRM等系统处理起来更加得心应手融会贯通。虽然个人有多年的电商开发经验自认为也非常了解商品系统什么产品、商品、货品、原料、辅料、SPU、SKU、渠道商品、属性、规格、参数、标签、包装方案、BOM等等都耳熟能详。可是真要严格说出个所以然来有些定义写出来真不那么让人信服本文还是先对照着搜索引擎摘录一下防止系统都做出来了对基本概念还稀里糊涂的让人觉得可靠性堪忧咩哈哈。1、商品马克思主义政治经济学认为人类劳动是最可贵的它可以创造价值。这就是马克思主义在经济学里最出名的一个理论即劳动价值论。根据这个基础的理论马克思给商品的定义是“商品是用来交换的劳动产品”。一个物品要想成为商品必须满足两个条件1、它必须是劳动产品一个物品要想成为商品它就必须是人类劳动的结晶劳动创造价值所有的商品都应该是人们劳动生产出来的也就是说必须凝结了一定的人类劳动。2、它必须是用于交换的假如一件物品其本身只是凝结了人类劳动但本身并没有用于交换而只是用于自己消费这种物品就算不上是商品因为商品最大的外在表现形式在于交换。商品的二重性商品二重性是指商品具有使用价值和价值两重属性。商品是用来交换的劳动产品具有使用价值和价值两种属性商品是使用价值和价值的统一。商品的有用性即能够用来满足人们某种需要的属性就是商品的使用价值。凝结在商品中的一般人类劳动就是商品的价值各种商品的价值只有量的差别而无质的不同。价值存在于商品体内是商品的社会属性体现着商品生产者相互交换劳动的社会关系。1、使用价值商品要能够交换就必须有用使用价值是物品能够满足人们某种需要的属性它是商品的自然属性是构成社会财富的物质内容是人类社会赖以生存和发展的物质基础。它体现了人与自然的关系。使用价值本身并不是政治经济学的研究对象。马克思政治经济学之所以要考察使用价值是因为商品的使用价值是其交换价值的物质承担者。一种物品要成为商品仅有使用价值是不够的它还必须是用来交换的即具有交换价值。商品除具有使用价值外还具有交换价值。交换价值是一种使用价值同另一种使用价值相交换的量的关系或比例。2、价值价值是凝结在商品中的无差别的一般人类劳动它是商品的社会属性也是商品所特有的属性体现了商品生产者相互比较和交换劳动的经济关系。马克思主义揭示了劳动是价值的源泉。价值是一个历史的范畴。作为商品的二因素之一价值是商品最本质的因素。3使用价值和价值的关系价值是使用价值的基础使用价值是价值的表现形式。商品是使用价值和价值的矛盾统一体使用价值和价值之间存在着对立统一的辩证关系。首先使用价值与价值是统一的。二者共处于一个统一体中缺一就不成其为商品。价值的存在要以使用价值的存在为前提没有使用价值的东西也就不会有价值使用价值是价值的物质承担者价值寓于使用价值之中。其次使用价值与价值又是不同的、矛盾的。因为第一对同一商品生产者或消费者来说同一商品的使用价值和价值不可兼得。商品生产者向消费者让渡使用价值以换取价值消费者为得到使用价值而支付价值。第二使用价值是商品的自然属性体现人与自然的关系而价值是商品的社会属性体现商品生产者之间的经济关系。 使用价值是一切有用物品包括商品所共有的属性是永恒的范畴价值是商品所特有的属性是商品经济的范畴因而是历史的范畴。商品之所以具有使用价值和价值两个因素是由于生产商品的劳动具有二重性。劳动二重性决定商品二因素具体劳动创造使用价值抽象劳动形成价值。 劳动二重性是商品二重性的根源。2、SPU和SKU1、SPUSPU Standard Product Unit 标准化产品单元SPU是商品信息聚合的最小单位是一组可复用、易检索的标准化信息的集合该集合描述了一个产品的特性。2、SKUSKU Stock Keeping Unit(库存量单位)SKU即库存进出计量的单位买家购买、商家进货、供应商备货、工厂生产等都是依据SKU进行的SKU是物理上不可分割的最小存货单元也就是说一款商品可以根据SKU来确定具体的货物存量。3、异同SPU和SKU都是一组属性名值对的大集合一组相似SKU抽象出的公共集合的统称可以认为就是SPU下面以一个通俗易懂的示例来直观理解SPU和SKU。华为P50 Pro手机是一种SPU生产于中国大陆基于鸿蒙操作系统于2021年上市的黑色机身内存128GB运行内存8GB...的华为P50 Pro手机是一个SKU。可以看到一种商品SPU包含多种SKUSPUSKU1、SKU2……SKU n且SKU唯一具有详细属性规格参数的SPU就可以唯一定义一个SKU。因为规格属性或参数的不同SKU容易产生组合爆炸难题。以华为P50 Pro为例关键规格有颜色黑色、白色、银色、金色、机身内存128G、256G、512G可以组合出4x312个SKU。从市场交易的角度来说SPU是一种抽象集合是无形的无法直接定价虽然直观理解是有价值和使用价值的但没有价格不能被交易而SKU有价值和使用价值也有价格可以进行买卖。通常我们口头上所说的商品其实可以直观理解为SKU。当然我们口头上说买了一部华为P50 Pro手机是不严谨的应该说买了一部黑色机身内存128GB运行内存8GB...其他属性的华为P50 Pro手机。特别提醒商品、SKU和SPU是完全不同的三个独立概念SPU到SKU再到商品是从抽象逐步到具体的过程商品模型决定了基本定义能否被严格区分但现实开发中常有人把它们混用而不自知。3、产品产品是指被人们使用和消费并能满足人们某种需求的任何东西包括有形的物品、无形的服务、组织、观念或它们的组合。在经济领域中通常也可理解为组织制造的任何制品或制品的组合。在现代汉语词典当中的解释为“生产出来的物品”。网上有很多文章将SPU说成是产品或者等价于产品个人认为是不太严谨的但是绝大多数电子商务环境下这么理解也是可以接受的。产品一般可以分为五个层次即核心产品、基本产品、期望产品、附加产品、潜在产品。1、核心产品是指整体产品提供给购买者的直接利益和效用2、基本产品是指核心产品的宏观化3、期望产品是指顾客在购买产品时一般会期望得到的一组特性或条件4、附加产品是指超过顾客期望的产品5、潜在产品是指产品或开发物在未来可能产生的改进和变革。简单来说就是“为了满足市场需要而创建的用于运营的功能及服务”就是产品。在交换的时空场景、过程中产品可以被称为商品也就是说产品和商品是可以互相转换的。产品和商品的主要区别产品不论是交换前与交换后都可称为产品。而当一种产品经过买卖交换进入使用过程后如果不存在交换场景中就不能再称之为商品只能称为产品。当这个产品又在交换的场景中的时候那么在这段即将发生买卖交换的时间空间内它又能被称之为商品。商品是用于买卖交换前的产品产品经过买卖交换进入使用阶段后就不能称为商品了只能称为产品。4、货品货品汉语词语读音是huò pǐn意思是货物也指货物的品种。百度百科里的这个2025年之前的旧解释真是坑爹简直就和没解释一样。我们再来看看几个流行AI工具对货品的定义是什么样的。1、通义千问2、字节豆包3、DeepSeek4、文心一言5、腾讯混元6、Kimi根据AI工具给出的解释我们能够得到如下结论1、商品更强调经济属性是指为交换而生产的劳动产品具有价值和使用价值。商品的核心在于“交换”。2、货品更强调物理属性是指具体的物品或货物通常指库存、仓储或运输中的物品。货品的核心在于“物品本身”。个人认为货品这个名词本身就是很抽象的定义对抽象本身再进行抽象实现的结果就可能挺抽象的。曾经某电商公司以货品来重写商品系统从设计之初到上线再到日常运营甚至公司关门大吉前都问题不断尤其是货品表的一把梭设计一张表一百几十个字段让人大开眼界咩哈哈。货品看上去是一种合理的抽象定义但实践证明不宜用于商品系统设计遗憾的是个人投入再多精力也无济于事。抽象和设计糟糕造成业务系统写不好不比刻骨铭心爱而不得好受多少。5、原料用于进一步加工的材料即为原料可以是其它加工过程的产物也可以是自然界生长或自然形成的产物。原料可以进行采购可以交换和买卖其价格往往是标准价格或按质论价典型示例如铁矿石等。原料在采购和买卖的过程中有使用价值和价值有价格这样就自动转换为了商品。6、辅料对产品生产起辅助作用的材料。示例服装的辅料有拉链纽扣兜标等附属物生鲜类产品的辅料有塑料箱、胶带等。辅料也可以进行采购可以交换和买卖在采购和买卖的过程中有使用价值和价值有价格这样就自动转换为了商品。7、BOMBOM Bill of Material叫做物料清单也叫产品结构表、物料表等。将产品的原材料、零配件、组合件予以拆解并将各单项物料按物料代码、品名、规格、单位用量、损耗等依制造流程的顺序记录下来排列为一个清单这就是物料清单也就是BOM。BOM是(1) 、物资需求计划Material Requirement PlanningMRP的基础。(2) 、制造令发料的计算依据。(3) 、本质上是一项工程文件不但是产品的规范说明而且是制造流程的依据。(4) 、用来核算产品成本的基础。由以上知道BOM的重要性及其影响范围很大故其内容必须随时保持正确及时。8、渠道商品发布到某个销售渠道的商品集合例如线下实体店、线上商城、自助售货机、无人售货商店等渠道。渠道商品在业务系统处理过程中往往会增加很多额外工作量以适配不同渠道。渠道商品的架构设计和实现非常考验开发者的水平和经验设计不好除了增加工作量和系统复杂度每次看到和维护不可描述的业务代码更是让人头疼这也是个人经验之谈。9、商品规格商品规格Goods specifications是指一些足以反映商品品质的主要指标如化学成分、含量、纯度、性能、容量、长短、粗细等。例如买衣服的商品规格指的是尺寸的大小一般的均码分大、中、小号有的较细上衣依据衣长、胸围、领长分大小下裤依据裤长短、腰围分大小等等。10、商品属性商品属性平常也叫商品参数是指商品本身所固有的性质是商品在不同领域差异性不同于其他商品的性质的集合。也就是说商品属性是商品性质的集合是商品差异性的集合。简单来说商品属性是描述商品维度的字段也就是商品的基本信息。属性或参数或规格它们其实非常相似当然商品属性、商品参数、商品规格的严格定义和区分一直有争议本文不做过多讨论。二、商品基础任何系统都会或多或少用到些字典型的基础数据商品系统当然也不例外。商品基础数据管理是主数据管理中非常重要的环节在电商活动中商品基础数据出现频率极高。本文简单介绍几种最常见的查询检索用到的基础数据包括品牌、分类、厂商等。1、品牌各种各样电子商务活动中出现频率最高的词汇之一就是品牌。2、厂商商品的厂商和品牌息息相关。品牌和厂商通过关系表进行连接查询品牌和厂商通常是一对一或一对多的关系。3、分类商品分类是商品分组聚合最常用到的技术和业务手段分类通常支持层级管理最多二到三级为宜很多电商公司分类层级都最多精确到三级分类。PowerDotNet实现的商品平台目前支持通用的三级商品分类满足绝大多数电商业务需求复杂度可控可扩展性也适中。4、分类分组商品分类自身也支持分组管理比如商品分类可以分为前台分类、后台分类、营销分类、手机分类等等按照业务需要进行扩展。当然商品分类分组不是必须如果分类设计的好可扩展性优秀完全可以适配多种场景不需要再独立进行分组管理。5、其他其他如商品标签、单位、产地、价保等基础数据本文不再列出。有些电商公司还会把尺码、颜色等抽象出来放在基础数据表里PowerDotNet实现的商品平台没有采用这种做法。三、SPU管理SPU的抽象能够大大简化商品管理。让我们再来复习一遍SPU的定义。SPU Standard Product Unit 标准化产品单元SPU是商品信息聚合的最小单位是一组可复用、易检索的标准化信息的集合该集合描述了一个产品的特性。1、SPU档案SPU包含的标准化的信息主要包括品牌、分类、厂商、区域、助记码等公共信息个性化的信息不适合抽象到SPU中可以在商品属性中独立添加或修改。SPU抽象的粒度非常考验业务或运营人员的经验和需求缺少经验的业务运营人员经常会需要不断变更SPU的定义。比如华为P40 Pro和华为P50 Pro可以定义成两个SPU也可以直接定义成华为手机Pn系列一个SPU这个就看实际运营需求通常情况下SPU管理宜细不宜粗越具体越好。SPU的管理对商品系统的稳定非常重要如果系统里SPU需要经常变动我们很可能需要重新抽象定义新的SPU。SPU字段较多新增SPU比较考验业务和运营人员的耐心当然对于相似的SPU商品平台提供了快速复制生成SPU的工具几个必填参数改改或者留空后台自动生成很容易就能添加一个SPU。2、审核SPUSPU的管理对商品系统的稳定是如此重要所以SPU所有新增或修改操作都需要人员审核所有关于SPU的操作都要添加审计日志特定环境或场景下可以依赖日志快速恢复或还原。3、生成商品SPU不是商品但是可以通过SPU工具自动批量快速生成最终售卖的商品有差异性的商品属性单独修改即可这样就可以大大简化商品的添加操作。四、属性管理商品属性是对我们通常所说的商品规格、商品属性和商品参数的通用抽象。PowerDotNet重写的商品平台对规格、属性和参数经过慎重考虑后进行了裁剪和取舍直接按照商品属性来定义商品元数据不延用规格而使用属性仅仅是因为作者的个人喜好咩哈哈。商品属性的表设计采用了经典的元数据设计大法按照属性名和属性值进行独立建表可扩展性非常好虽然查询检索可能会比较复杂但是有成熟的技术手段如Lucene、ES等全文检索技术优化查询。属性名值对支持文本、单选和多选设计这种设计方法对于电商系统中常见的单规格商品和多规格商品可以完美支持。有了元数据设计法品牌、分类等商品基础属性通过名值对字典表也能完美适配但很多电商都独立设计这几张数据表一个原因是查询频繁另一个可能是品牌有图片分类有前台、APP显示名称等业务字段较多。1、属性名属性名支持分组管理这个抽象通常都是后台管理用到前端逻辑不需要过分关注。属性名也支持层级管理通常不那么复杂的电商场景只设计一级属性名即可。2、属性值根据属性名定义不同的属性值对于单规格商品就设置一个值多规格商品就设置多个属性值。3、商品属性属性名和属性值定义好了最终是要作用于商品上的否则单独设计属性名和属性值也没有意义。商品、属性名和属性值可以通过传统的中间关系表产生关联这样可以达到属性名值对作用于商品上的效果。PowerDotNet实现的商品平台更进一步设计了商品属性表这张表对属性名和属性值进行了大量冗余。这样设计的优点是属性名或者属性值变更时不会影响到现有的商品属性缺点也比较明显某些查询场景下需要行转列处理冗余数据略多如果相同的改动就需要作用于大部分商品可能不得不改动大量的冗余数据。PowerDotNet开发的商品平台有商品属性名和商品属性值自动同步功能可以按照商品、SPU、分类、品牌等不同维度和粒度进行批量同步数据操作大大减少属性数据变更导致的业务和运营人员的工作量。当然这个中间商品属性表的维护还是需要人员花费大量精力和时间毕竟商品属性很多幸好有模板设计法PowerDotNet内置了很多模板工具和方法可以进行批量增删改操作同样能大大减少工作量。不得不说元数据大法好模板大法好PowerDotNet大法好咩哈哈。五、模板管理电商平台的商品琳琅满目属性成千上万如果我们对商品属性管理按照商品一个一个进行录入工作量巨大而且容易出错。通过模板设计大法我们完全没有必要按照商品进行一个一个管理可以先定义好属性模板按照SPU、分类、品牌等进行模板管理只需要录入必须的基本的属性名和属性值就可以按照模板批量管理。当然模板生成的商品属性通常都是通用的没有明显差异化的需要个性化的商品属性我们可以按照商品一个一个进行补充这种操作通常很少工作量完全可以接受。1、模板信息可以按照SPU、分类、品牌等分组命名模板望文知义所见即所得便于运营和管理。2、模板属性定义模板是为了解决属性繁多易错的问题所以模板就要和属性名、属性值产生关联关系。3、复制模板对于相似SPU、分类或品牌PowerDotNet商品平台提供了快捷复制工具可以按照已有模板批量复制模板和模板关联属性大大减少业务工作量。4、同步模板模板的改动相对而言比较少但是如果有变更比如属性名值的增删改我们可以通过同步工具自动批量将变更数据同步到各个商品中业务要做的事情就是点下按钮而已。5、SPU模板一种SPU可以包含多种商品定义好SPU模板可以一键生成相同SPU下的一组商品的商品属性差异化的属性再到商品属性管理页面下独立设置修改即可。举例SPU为华为P50 Pro主要差异属性有颜色黑色、白色、银色、金色和机身内存128G、256G、512G定义好模板可以一键生成4x312个商品的所有商品属性。根据SPU自动生成商品的过程其实也是自动生成SKU的过程但这个过程在PowerDotNet商品管理里可以弱化后续介绍SKU的时候再介绍下为什么要弱化这个过程。6、分类模板如果某些分类下的商品属性非常相似可以定义比SPU更粗力度的模板批量生成相同分类下的商品属性差异化的属性再到商品属性下独立设置修改即可。举例三级分类为手机定义好分类下的模板可以一键批量生成手机分类下的商品属性。7、分类品牌模板和分类模板的主要功能和作用类似只不过分类品牌模板是在分类相同的情况下再找到相同品牌的商品商品范围被缩小差异化的属性再到商品属性下独立设置修改即可。举例三级分类为手机品牌为华为定义好分类品牌下的模板可以一键批量生成手机分类下华为手机的商品属性。六、商品管理商品管理模块主要包括商品信息、商品属性、商品条码、商品价保、商品图片、商品视频等常用功能。有些公司的商品管理代码对很多基础概念那叫一个不讲究尤其是SPU和SKU规格、属性和参数等容易混淆的内容有经验的人看过就知道不出意外的话总有一天会出意外。1、SKUSKU Stock Keeping Unit(库存量单位)严格按照定义来看显而易见SKU肯定不完全等于商品实际情况也确实是这样的商品定义远远比SKU要复杂的多商品要应对的变化也远比SKU复杂。在传统的商品管理体系设计和实现中商品管理一般都会包含SPU、SKU和商品信息三层管理逻辑商品ID(GoodsId)、SkuId和SpuId之间有关联关系抽象程度越高定义越明确商品更容易管理。个人经验中SKU主要基于商品的销售属性生成常用于库存和价格管理后台控制更多而商品的整体定义除了销售属性还有条码、图片、视频和营销等等各种元素前后台都有复杂控制逻辑。SPU可以根据模板自动生成SKU和商品SKU属于商品和SPU之间的过渡角色如果你开发过的WMS、MES和商品管理系统CMS都是以商品为准SKU的地位就很尴尬让人几乎感觉不到它的存在。PowerDotNet的SKU设计参考了前厂的商品管理商品和SKU仅有简单的关联关系实际商品管理都是以商品为准弱化了SKU的存在WMS和MES中的商品库存也是商品为准这就是理论和实践的区别。2、商品档案支持商品信息的增删改查支持快捷生成商品。通过模板可以批量生成商品属性通过SPU可以一键批量生成商品。PowerDotNet实现的商品信息管理兼具易用性和可扩展性查询也比较方便对于中小公司甚至不需要上全文检索直接创建宽表根据RDBMS的查询功能即可实现基本业务需求。商品信息字段比较多商品管理后台提供了完善的偷懒工具只要点击复制按钮必填参数改一下或者不填由后台自动生成可以大大提高录入数据速度和准确性对于同品类或相同SPU的商品有奇效。3、商品属性商品信息里的字段主要是常用检索字段和通用信息字段商品属性定义更丰富的商品维度描述。字典表属性名和属性值修改后可以批量同步到商品属性中这是一个比较危险的操作尤其是销售属性的批量同步变更需要业务反复查询对比确认后才能操作。前面属性管理处我们已经说过PowerDotNet实现的商品平台对商品属性表做了大量冗余支持自定义支持修改特定商品属性名值对而不影响全局。4、商品条码条码的应用非常广泛PowerDotNet实现的商品条码支持商品普通条码和二维码的生成。某些商品还需要按渠道不同生成特定渠道的条码和二维码PowerDotNet预留了扩展用以后续支持。商品条码和商品库存有一定的关系通常情况下相同商品SKU的有效条码可以重复重复个数和库存数相等当然不严格的情况下条码也可以重复生成或作废并不强求条码和库存数一定相等。5、商品价保价保基础表定义价保信息商品再根据商品和价保关系表构成商品价保这样设计的好处是价保信息可以复用。其中价保关系表还特别设计了价保开始和结束时间满足绝大多数电商促销活动的需求。当然有些电商的活动规则引擎会把价保自动放到规则中去不需要在商品系统中进行价保维护。6、商品图片商品图片主要利用文件平台Power.File实现图片的管理本文不再赘述。7、商品视频和商品图片类似目前短视频极其流行视频文件大小较大对文件服务器有较高要求。8、商品统计电商系统中商品众多排序在商品展示中有重要作用常见的排序指标比如评论数、收藏数、销量等等这些数据主要由统计计算而来直接设计存储在商品系统中非常合理当然这些数据存储在其他系统如CRM、订单等中进行汇总定时通知到商品系统或者商品系统主动调用接口查询也是常见的可行方案。9、其他其他如商品买家秀等个性化数据没有设计在商品平台里个人认为这些模块功能属于商品系统的可扩展设计对于中小电商系统它们完全可以划归到Power.PCRM中去。商品库存则很明显需要开发库存或者进销存系统进行商品库存管理复杂点的库存管理系统还需要包括原料、辅料、生产加工等等功能模块这些正是WMS和MES系统的长项。为了查漏补缺我试着问国内几个主流AI工具相同的问题“提供一份电子商务商品系统主要的数据库表设计”最终比较满意的竟然是字节豆包而我预料中最可能接近答案的通义千问还不如DeepSeek给的结果靠谱。七、日志管理商品平台是电商系统最基础最重要最敏感的业务系统之一所以对商品的增删改操作都要有业务操作日志某些核心查询操作也需要按需记录审计日志。1、商品日志主要用于记录并管理商品的核心操作日志特殊情况下还可根据这些日志进行业务数据还原和恢复。根据个人经验所有基础数据表的修改自定义商品属性、销售属性、价格等敏感参数都需要重点记录日志防止修改错误需要紧急修复。2、系统日志系统日志相对商品日志重要性就不那么突出主要记录一些日常操作日志、对外提供接口日志、业务不敏感日志等。系统日志可通过定时任务自动归档或者清理。八、特殊商品上面列举的一系列商品功能只是最通用最基础的电商商品抽象还有一些特殊商品正是我实现过程中痛苦和挣扎的主要来源可能还需要按需进行额外扩展设计和管理。Power.Commodity一开始只是我没事写点代码让自己高兴高兴的临时作品目的也只是单纯总结和提取个人工作过的商品代码但写着写着就发现越来越深不见底尤其是特殊商品实在难以全部覆盖。本文不探讨特殊商品的具体管理设计开发和建设细节因为这是另外一个漫长的故事了对于体力活我也是有追求的所谓识时务者为俊杰^_^只简单说说个人实际参与设计开发过的几种特殊商品。1、汽车商品汽车商品是一种特殊商品区别于一般商品的主要特点包括1、零件多技术含量高属性多且复杂2、金额较大3、耐用品4、涉及重大安全问题5、有专属的交通法规管理人员道路辅助等6、大件重量较大不易快递或转运配合门店或4S店销售7、是高档金融消费品和金融保险联系紧密8、其他如税费较多汽车商品常见的5种税车辆购置税、车船税、增值税、消费税、关税除车款外其他费用包括上牌费、保险交强险、商业险等多层级属性是汽车商品的一个显著特点汽车商品常见的一级属性包括品牌、厂商、车系、车款、车身、发动机、电动机、变速箱、底盘转向、车轮制动、安全装备、操控配置、外部配置、内部配置、座椅配置、多媒体配置、灯光配置、玻璃/后视镜、空调/冰箱、高科技配置等每一个属性下又可以继续拆分出不同的子属性比如多媒体配置我们可以继续拆分出GPS导航、定位互动服务、中控台彩色大屏、蓝牙/车载电话、车载电视、后排液晶屏、外接音源接口、CD支持MP3/WMA、多媒体系统、扬声器品牌、扬声器数量、220V/230V电源系统等子属性。相比普通商品汽车商品查询检索有较多的多规格设计常见的除了分类和品牌外还包括价格、排量如1.1-1.6L、1.7-2.0L、能源如汽油、新能源、结构如两厢、三厢、国别如中国、欧系、配置如全景天窗、电动天窗、驱动、变速箱、座位、进气形式、生产方式等。个人开发经验中和汽车这种巨多规格和属性的商品类似的还包括药品和生鲜类商品对于这种繁多而复杂的商品一张宽表一把梭的设计特别容易造成开发和维护灾难。PowerDotNet的商品属性设计和模板方法完全可以应对汽车商品的多规格属性配置只是属性层级多属性字段也很多查询逻辑略微复杂。2、生鲜商品生鲜商品的最大特点是任意性和随意性正是因为这两个特性导致生鲜商品的标准化远远滞后于一般商品而标准化在商品平台设计与实现中至关重要。我们还是以前面提到的华为手机举例通过一个简单示例对比看一下标准化生鲜商品为什么会比较困难华为P50 Pro手机是一种SPU生产于中国大陆基于鸿蒙操作系统于2021年上市的黑色机身内存128GB运行内存8GB...的华为P50 Pro手机是一个SKU。相对应的生鲜类标准化商品会有如下描述南汇8424西瓜是一种SPU产于中国上海的于2021年上市的重量为XX公斤到YY公斤...的南汇8848西瓜是一个SKU。人不能两次踏进同一条河流这是古希腊哲学家赫拉克利特说的。西瓜不能两次长出同一种重量我们也可以说的富有哲理咩哈哈。假如标准化不加约定和限制仅仅根据生鲜类商品的重量就能组合出很多种商品造成SKU组合爆炸难题。有人可能会有疑问为什么不按照单位重量或体积进行商品定义比如产于中国上海的于2021年上市的每公斤5元的南汇8848西瓜是一个SKU然后用户下订单直接按照实际购买重量乘以单价即可。这种方案看上去非常完美但是有一个先天缺陷重量是需要人力称出来的生鲜电商由于是大规模线上经营通常都是预先通过生产加工系统进行称重然后更新库存不可能像实体店那样当面现称现卖。这个问题的解决方案就是针对特定生鲜产品进行评估对相同SPU的商品给出一个大致模糊的重量或体积范围以满足生产加工的需要商定出一个用户能接受的价格达到一种买和卖的平衡。在一些电商站点上生鲜商品比普通售卖的商品看上去没有更加复杂有些行业特点比如储运条件常温、恒温、冷冻、冷藏等通过属性名值对或者扩展表也能很好支持之所以拿出来单独说主要是因为生鲜商品标准化背后隐藏的复杂性。生鲜商品非标准化的物品很难用标准化的商品软件来管控很多生鲜电商公司都只能按需自研信息化服务比如供应链、生产加工、仓储管理、质检、运输、配送等等难度可想而知。个人曾经参与开发维护过一套生鲜系统业务逻辑之恶劣实现之奇葩单据之多样软件流程之长使用之不友好每看一遍代码都差点灵魂出窍业务系统做成这种效果也是常人所不能及也。咩哈哈。我尝试过用PowerDotNet新的商品设计思路重构一个生鲜商品系统但是难度和工作量极大还会影响其他系统最后只能撤销改动放弃努力曾经有过美好但有些事物失去了就是失去了不可强求。假如商品平台要支持生鲜商品的主要特性可能原料、辅料、包装方案、BOM、计划单、提货单、加工单、反加工单、损益单、尾料、原料顶替等名词都要再温故知新一遍往事历历在目却遥不可及也。通用性、标准性和普适性的公共服务系统才是PowerDotNet努力的方向而任意性和随意性天生就是公共服务的天敌抽象和实现的难度肉眼可见成倍剧增所以最新商品平台设计暂不支持生鲜类商品。3、虚拟商品最典型而常见的几种虚拟商品如下1、网络游戏卡是按服务公司的规定以现金兑换虚拟点(积分)的形式通过消耗虚拟点(积分)来享受服务的一种支付形式。2、移动/联通/电信/充值包括话费充值流量充值等。3、网络软件一般是指系统的操作系统、协议和应用级的提供服务功能的专用软件。4、网站产品以产品的眼光看待网站是网站产品的精髓所在。网站产品不同于软件产品、服务产品、工业产品等。网站产品是一类信息产品以网站的形式提供信息、服务或二者的结合是它的主要表现形式。我个人最熟悉的虚拟商品包括网文按章节收费和电子书以及游戏点卡某些公司的虚拟货币充值也可以抽象成一种商品只要让用户下订单花钱支付购买同时又没有直接拿到实物产品就可以认为用户购买的是虚拟商品。4、服务商品服务型商品也是日常生产生活中经常碰到的一种商品类型。最典型的如火车票、汽车票、酒店、机票、旅游度假等商品。以我个人比较熟悉的某OTAOnline Travel Agency在线旅行社机票产品为例服务型商品也非常考验开发人员的设计和架构水平。机票系统涉及到很多业务数据表常见的比如区域、二字码、三字码、机场、航站楼、航线、航司、飞机机型、中转地、行程总时长、仓位、常旅客、机票、机票库存、报价信息等表。机票、火车票、汽车票、船票和邮轮等非常相似看上去都是一个“占座”的商品形式完全可以抽象出公共部分。而酒店则有一个间夜的概念外加酒店内的附属商品管理复杂度更胜一筹。我们可以将机票航线、航班号、起降时间和具体飞机及仓位的组合也就是一张飞机票直观理解为商品常见的机票商品包括单程和往返机票还可以根据不同航线组合出联程/多程机票。对于机票大家还应该听说过中航信含eTerm 或IBE两者都知道的我只想说吾道不孤矣机票查询和预定基本离不开它。注IBEInternet Booking Engine即中国航信互联网订座引擎是基于因特网的开放平台技术它为各种用户应用系统提供访问中国航信传统订座业务系统的途径是采用API方式的接口。据我所知机票库存可以通过中航信的eTerm软件来查询行业内的一般做法是将eTerm软件功能封装成接口供内部系统使用当然除了eTerm现在还有IBE以API接口的形式提供查询和预定功能。机票的库存信息一般称为AV信息这个称呼的来源主要源于eTerm黑屏查库存指令。由于库存信息非常重要因此每家OTA都会花费很多的流量在获取航班的AV信息上。由于eTerm和IBE的接口响应时间较慢因此OTA采用的方法基本都是主动去获取AV信息然后缓存起来绝大多数用户查询时直接拿缓存数据即可当然有些情况下还是会出现查询缓存失败再去实时获取AV信息的情况。相较于汽车、生鲜和虚拟商品PowerDotNet的商品系统可能只需要加一些业务扩展表就可以完美支持而服务类商品通常业务复杂不容易做成通用设计所以PowerDotNet已完成的商品设计将服务商品排除在外。我尝试着使用国内流行的人工智能服务通义千问、字节豆包、DeepSeek、文心一言和腾讯混元实现机票预定功能给出的代码真是一言难尽AI目前还无法给出超过预期的方案祖传代码暂时还是安全的^_^。假如后续仍然需要加入机票、酒店、火车票、汽车票等服务商品功能最好按照服务商品的特殊规范进行抽象设计独立出来服务商品平台未尝不是一个好方法元数据和模板设计大法同样有用武之地。当然目前看来PowerDotNet实现的商品管理系统还是比较基础的传统的商品管理想做到大一统的支持各种形态的商品还需要做很多设计和实现工作虽然我个人手头有现成的业务代码和解决方案可参考咩哈哈。九、商品搜索1、实现功能商品搜索实现的功能主要包括按关键字搜索、中文分词、历史搜索、热门搜索、推荐搜索、联想关键词等等绝大多数大中型电商公司的全站搜索服务就包括商品搜索功能。2、解决方案商品搜索在商品管理上算是常用而又有点技术难度的功能了曾经有一种简单直接高效的暴力设计方法就是添加一张商品关键词表不过随着NoSQL和NewSQL的兴起这种设计方案已显得非常落后。个人早年有幸独立实现过一个典型而朴素的商品搜索功能按照商品分类、标签以及任意关键字通过MySQL的查询功能模糊或精确匹配按权重分页展示现在想来依然十分好笑咩哈哈。搜索有很多现成的解决方案比如基于Lucene或者ElasticSearch全文检索实现的搜索服务按不同数据源比如商品建立索引通过分词优化匹配查询索引可按需实现对应系统如商品查询服务。Lucene和ElasticSearch在实践中极易一不小心踩到很多坑尤其是ElasticSearch个人印象最深的是看上去简单常用的分页查询在数据量很大或者有较多分片的情况下越往后分页查询性能越拉跨。个人曾经所在电商公司使用ES实现基本搜索功能外加Redis和SqlServer配合实现搜索服务兜底方案性能恶劣的sql语句like模糊匹配是最差的选择like查询默认选择可以使用索引的左匹配。搜索服务的设计与实现比较有技术挑战尤其是全站搜索和商品搜索结合值得再开一篇文章详细介绍不过这就是更偏重于分词索引实现搜索服务的另一个话题了本文不再展开详细说明。十、商品排序商品搜索和商品排序是密不可分的对于商品搜索结果我们总是要根据一定的排序规则展示给用户。下面列举电商中常见的几种商品排序1、直接根据商品属性排序比如商品价格、上架时间、商品序号、自定义排序序号等2、根据商品相关统计进行排序比如商品销量、好评数、关注数、浏览次数、回购率等3、根据商家相关统计进行排序比如商家信用、商家门店数等4、根据距离排序最常见最典型的就是在线外卖订餐平台根据消费者当前位置按照距离排序5、综合排序在实际电商业务场景中系统默认推荐排序不是简单的根据单一字段进行排序而是综合排序。通常来说综合排序是先按商品和搜索关键词的相关性过滤然后按上下架时间做预选最后在预选结果里根据商品人气及质量等方面进行排序。十一、系统交互商品系统是电商最核心的组成部分之一是电商平台的基础数据服务系统和很多内部业务系统保持互通关系整理下个人开发和对接过的几种常见互联系统。1、订单系统毫无疑问订单的生成离不开商品企业在正常的经营过程中必须有销售商品、产品、提供劳务等业务订单系统主要提供商品售卖服务。2、库存系统库存系统主要用于管理商品库存主要包括商品入库、商品出库商品调拨和商品盘点等操作。我们熟知的仓储WMS系统就包括库存管理。3、采购系统电商中的商品一般来说主要由供应商提供我们常见的采销系统或进销存系统或供应链系统等都和商品及库存紧密相关。某些特殊电商场景除了商品还要考虑辅料、原料物料等商品管理系统的设计直接关系到采销业务系统的复杂度。4、门店系统门店系统主要经营企业线下业务门店系统的经营活动也离不开商品管理系统。5、财务系统财务系统是电商系统中最复杂的复合型公共服务型系统财务单据经常和商品管理有千丝万缕的联系。十多年前在帝都某电商公司做财务开发竟然要自己写SQL访问商品表的积分字段写windows服务计算和统计用户积分这么普通而自信的业务逻辑放在今天你敢信这些其实都是要规避的不合理设计。6、票券系统票券系统是电商中常见的营销系统针对商品分类、SPU甚至SKU的票券设计很常见。7、广告系统广告系统也是电商中常见的营销系统针对商品的广告宣传层出不穷。8、推荐系统电商里的推荐系统不会孤立存在往往和商品、CRM、订单等系统配合完成业务需求。9、CRM主要包括针对个人用户或会员的商品偏好收集和购买统计、积分赠送等等10、其他系统其他如活动等电商业务系统也和商品管理有些联系。十二、其他个人参与设计与开发的商品系统还涉及到以下功能1、商品详情一个好的商品详情页可以有效的提升单品的转化率对于不同终端比如PC、APP、H5等的商品详情页设计侧重点也会有很多不同。商品详情页的接口设计也非常考验开发人员的编程经验是采用大而全接口还是小而美接口这需要开发人员根据实际情况做出合适的选择。2、多语言商品的多语言设计和实现也很普遍对数据表的设计有更多更高要求虽然多语言的工作绝大多数在我看来都是体力活。3、组合商品为了促进销售很多商家在售卖时会利用“捆绑销售”的策略这样就自然而然发明出了组合商品人为将几个单独售卖的商品组合在一起进行合并售卖的商品。SKU(组合)m*SKU1n*SKU2...p*SKUx组合商品的设计可能会对商品库存管理和订单拆单逻辑造成直接的负面影响曾经在某电商公司做过一段时间开发没少被组合商品搞得晕头转向尤其是某些单据的业务逻辑那是相当炸裂。4、商品数据同步不同系统对商品主数据的要求是不一样的有些业务系统仅仅提供商品接口即可满足业务需求比如订单系统。但一些后台业务系统如WMS、MES等往往牵涉到商品的复杂SQL查询商品数据同步至对应业务系统也是必要的PowerDotNet数据同步平台Power.DataX可轻松解决数据同步问题。作者Jeff Wong出处http://jeffwongishandsome.cnblogs.com/本文版权归作者和博客园共有欢迎围观转载。转载时请您务必在文章明显位置给出原文链接谢谢您的合作。