这个问题的核心点在于:不同商品类别差异很大,如何设计通用的存储方案?简单来说,用数据库去存储所有信息,不管横表还是纵表,都有明显的缺陷:横表:同一个字段对不同商品含义不一样,这到了后面开发和维护是很蛋疼的纵表:一个商品的属性分布到很多行记录中,业务处理很麻烦,而且纵表的记录数会非常多,性能会有问题所以不要尝试只用数据库去统一解决这个问题,思路扩散一些其实就简单了:公共表:提炼商品公共的信息放到数据库,例如商品id、名称、发布的商家、发布日期、上架状态扩展表:将变化的信息放到另外一个表,可以是数据库表,例如电脑商品一个表、服装一个表;也可以将信息放到MongoDB或者ElasticSearch这类文档数据库。搜索组件:扩展表在全文搜索的时候不好实现,因此需要独立的组件负责搜索,可以用Elastic Search或者Solr来冗余一份数据,用于搜索。表结构不算复杂,因为项目关系只有SPU,没有涉及到SKU,但是可以做参考,更多的还是要根据项目实际情况设计。重点说明一下产品表的SPU,Keyword字段。本来之前设计了关系表,但是发现在做SQL查询时太痛苦,所以约定了一种数据存储结构(数据结构的重要性)基于上面的基础,可以实现URL规则变化的查询,类似京东的产品查询URL变化c=1,3 指分类层次关系ev=3_1+4_18 指SPU查询 按约定规则转换成字符串再进行查询。
SPU(Standard Product Unit):标准化产品单元。一、它是商品信息聚合的最小单位,是一组可复用、易检索的标准化信息的集合,该集合描述了一个产品的特性。通俗点讲,属性值、特性相同的商品就可以称为一个SPU。
一、另一方面,这些“属性|属性值对”在SPU中固化下来,逐步标准化。
基于SPU的商品信息结构,可以实现丰富的应用,比如商品信息与资讯、评论、以及其它SPU的整合。
例如:iPhone X 可以确定一个产品即为一个SPU。
SKU是一个库存量单位。
SKU全称为Stock Keeping Unit(库存量单位),即库存进出计量的基本单元,可以是以件,盒,托盘等为单位。SKU这是对于大型连锁超市DC(配送中心)物流管理的一个必要的方法。现在已经被引申为产品统一编号的简称,每种产品均对应有唯一的SKU号。
扩展资料:
维持SKU平衡
首先要指定判断滞销商品的方法,当商品在商城/渠道店铺的销售业绩呈现什么情况的时候即可被认定为滞销商品,例如有些电商将超过两个月无销量的商品视为滞销商品。
然后,分析商品滞销的原因,根据滞销商品的问题采取应对措施。比如在商城/渠道店铺的日常营运管理过程中,每天运营负责人召开的晨会中要涉及滞销商品跟踪,这需要IT部门每日提交以渠道(比如:淘宝渠道,拍拍渠道,京东渠道等)为单位的滞销商品清单。
由运营负责人根据清单督促各个渠道店长采取措施尽快处理滞销商品;同时采购部门也会得到同样的滞销商品清单,与供应商召开会议商讨如何解决滞销商品问题。
所有这些工作的目的是通过退货或促销等手段,尽量减少由于商品滞销而对电商可能带来的损失。其中,运营与采购部门同时努力,是滞销商品得以有效控制和清理的关键。
每天跟踪就是要将滞销商品的跟踪作为电商营运和采购部门管理每天必须关注的工作内容之一。电商不能发现滞销商品首先想到的就是退货,其实重点是要分析产生滞销的真正原因,是否有更好的解决方法。
当然,在滞销商品的清理过程中,如果确认滞销原因是因为商品本身问题,那么引进新品替代滞销商品是必须要进行的工作,否则此分类中的SKU数量就会减少。虽然这并不是很严格的一进一出原则,但维持整个SKU数量平衡对电商来说非常重要。
如果电商在整个管理过程中制定了清晰细致的控制流程和管理制度,并在商城/渠道店铺日常经营中很好地去执行,定能使商城/渠道店铺处于高效的运营状态。
参考资料来源:百度百科-SKU
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)