当前位置:威尼斯 > jave > 是需求和流程,区分单品

是需求和流程,区分单品

文章作者:jave 上传时间:2019-09-29

想做一个B2B2C的电商平台,在后台数据统计搭建的时候需要注意哪些问题?如何设计具体的统计模块?

/**************2016年4月25日 更新********************************************/

王于萍:

知乎:产品 SKU 是什么意思?与之相关的还有哪些?

我认为在建数据库前,需要设计好的,是需求和流程,有了这一步的需求,你就知道了在这里你需要什么数据;有了流程,你就知道了你能得到什么数据,甚至于数据类型。

 

比如供应商管理,你会得到供应商的公司地区、电话、类目等,在数据统计中,你可以对地区、类目统计,再根据C的对应需求推荐等

kentzhu:

PalmWong:

在电子商务里,一般会提到这样几个词:商品、单品、SPU、SKU

建议先从业务理解开始:

 

BBC平台,首先分成三个后台

简单理解一下,SPU是标准化产品单元,区分品种;SKU是库存量单位,区分单品;商品特指与商家有关的商品,可对应多个SKU。

商家门户+平台运营门户+买家个人门户

 

要做统计的部分同样是三块:

首先,搞清楚商品与单品的区别。例如,iphone是一个单品,但是在淘宝上当很多商家同时出售这个产品的时候,iphone就是一个商品了。

1、消费者个人视角出发:个人的消费统计

 

2、平台运营的视角出发:整个平台的运营情况统计,针对商家的运营情况统计

商品:淘宝叫item,京东叫product,商品特指与商家有关的商品,每个商品有一个商家编码,每个商品下面有多个颜色,款式,可以有多个SKU。

3、商家视角出发的统计

 

BBC商城其实是非常复杂的业务系统,因为角色和功能的变化,导致其中数据交互其实非常多。且对账、统计、权限管理异常情况很多。

SPU = Standard Product Unit (标准化产品单元),SPU是商品信息聚合的最小单位,是一组可复用、易检索的标准化信息的集合,该集合描述了一个产品的特性。通俗点讲,属性值、特性相同的商品就可以称为一个SPU。例如,iphone4就是一个SPU,N97也是一个SPU,这个与商家无关,与颜色、款式、套餐也无关。

不是看着天猫的模式,就闭着眼睛可以做的。

 

用 PHP+MySql 架构用户数和访问量为千万级别的类似淘宝商城那样的 B2C 网站,如何?

SKU=stock keeping unit(库存量单位),SKU即库存进出计量的单位, 可以是以件、盒、托盘等为单位。在服装、鞋类商品中使用最多最普遍。 例如纺织品中一个SKU通常表示:规格、颜色、款式。

Dion:

 

系统架构很重要!

SKU是物理上不可分割的最小存货单元。在使用时要根据不同业态,不同管 理模式来处理。比如一香烟是50条,一条里有十盒,一盒中有20支,这些单位就要根据不同的需要来设定SKU。

语言:

 

主流语言都没什么问题。PHP、Java什么的都行。

老黄的实验室:

前端服务器:

spu,sku,item,规格,单规格商品,双规格商品,三规格商品…

如果有条件CDN,最好。没有的话,一定要保证前端的负载性能。一般推荐Nginx。

 

应用服务器:

服装为例:

集群呗。前端负责负载均衡。集群的话,Session的问题注意下就行。别的没什么。

一款衣服,是一个spu

数据存储:

这款衣服,有黑白两个颜色,小中大特大四个尺码,颜色和尺码就是他的两个规格,每个颜色和尺码排列组合,组成最终的sku。

如果数据量比较大的话,用MySQL + Memcached做集群没问题。

 

如果数据量再大的话,考虑NoSQL吧。比如Facebook用Cassandra,Amazon用Dynamo。

iphone6为例:

socici:

iphone6是一个spu

你可以简单点,从用户访问的数据角度看

规格1-颜色,包含黑色白色,土豪金

静态文件,包括图片、HTM 、JS、css 这些不经常变的数据。 单独给个域 如 由nginx管理

规格2-容量,包含16G,32G,64G,128G

通过前后台发布的动态数据,分以下几种:

规格3-制式,移动版,联通版,电信版

读的数据:

规格4-合约,合约机,非合约机

1.需要用户查询的大数据,如订单之类的,可以去查slaver的数据库

把每个规格都排列组合一下,就是最终的sku

2.系统公共页面显示的数据,如部分商品信息、排行榜之类的可以去缓存里取

 

写的数据:

知乎:有哪些常见的数据库优化方法?

要求即时生效的,如修改用户信息,直接同步写到master数据库

 

即时要求不高或者有并发限制的,如发微博、发私信之类的 先写到队列,异步读取保存到数据库

谢龙:

电商平台中商品规格设计的问题,抛出,求吐槽?

1.善用explain,看看自己写的sql到底要涉及到多少表,多少行,使用了那些索引,根据这些信息适当的创建索引;

商品表(商品名称、价格、上下架等一些商品基本的信息)

2.善用不同的存储引擎,MySQL有多种不同的存储引擎,InnoDB,Aria,MEMORY根据需要给不同的表选择不同的存储引擎,比如要支持transaction的话用InnoDB等;

例如:1、 手机、100

3.表很大的时候,做分片。

规格表(主键、商品ID、规格名称 )

 

例如:1 、1、运营商

惑春秋:

商品规格值表(主键、规格ID、商品ID、规格值ID、规格值NAME)

数据库物理层:
1)数据库系统软件应该尽量跟数据文件分置不同存储设备
2)如果可能数据库临时空间、log尽量使用快速存储设备
3)数据文件应该根据具体应用需要分置不同存储设备提高读取效率
4)数据文件使用RAID既保障数据安全又有利性能

例如:1、1、1、0、电信版

数据库逻辑层
1)为数据库system表空间、user表空间、应用表空间分离
最起码user和应用不应该使用系统表空间
如果可能三类表空间应该分在不同物理存储上
2)应用表空间中
表的表空间、索引的表空间也应该分离
3)创建表时应该考虑表的特性
比如有些表大部分时候是只插入记录很少修改删除
有些表是所有记录经常增、删、改
有些表只有少数字段
有些表有大量字段但大部分时候其中大半字段为空
有些表数据增长很快
有些表数据常年基本不变
等等
不同特性的表应该在创建时定义不同的起始空间和空间增长方案
以尽量让一条记录处于一个连续的物理存储空间提高读取效率
另外要制定不同的备份恢复和碎片整理机制
4)索引不是越多越好
而是因表的特点而不同
数据变化频繁的表还应该建立索引定期重建机制
否则索引不但不会改善性能还会降低性能
5)某些应用常用表比如lookup code之类的
如果可能尽量建在独立的表空间上
并把表空间建在快速存储设备上

2、1、1、1、移动版

上面这些对SQL Server一类轻量级的数据库也就差不多了
但对于Oracle DB2这种重量级数据库
还有内存管理优化
太久不做一时有点儿理不清头绪了
以后想起来能补再补

规格库存表(商品ID、规格值ID组合、规格值NAME组合、库存量、价格)

数据库应用层
这个太多了
首先Modeling要合理
这个太重要
应用设计不合理再怎么优化、谁来优化也只是死马当活马病

其次是代码中的SQL语句优化
比如查询尽量使用索引
尽量不要做全表扫描
慎用子查询和Union All
多表join时尽量用小表去join大表
(注每个数据库厂商对join的处理不完全一样
此处的优化应该参考数据库厂商的用户手册)
等等等等

例如:1、1/0(运营商、电信版)、运营商/电信版、100个、100块

 

问题描述:

 

以上方式可实现多规格多库存但是采用一种约定的规格顺序,感觉在编写程序时,系统在后期统计不同规格相关的数据就会很痛苦。

知乎:mysql的数据库设计到底该不该加约束

并且在实现商品创建时,要先把商品创建好后,才能创建规格,个人参考一些大的电商平台方式,发现都是一个提交完成商品创建。

比如非空约束,外键约束等。因为我看到我们公司的DBA在设计数据库结构的时候都是不加任何约束的,这样对性能的提高有多大,会不会影响到数据的完整性。新手求大牛解答?

需要的帮助:

joylisten:

需要结合我的问题描述,给一个合理的商品多规格、多价格、多库存的设计方案,来解决我编程上的复杂度,同时保证我可以在商品创建的交互设计中简单。

学院派会告诉你在设计的时候把应该有的约束都加上

socici:

 

商品分类 (类型id,类型名称,父ID)

而实践派得出的结论是主键一定加,非空约束尽量加,外键最好依赖于程序逻辑,而不是数据库,从而更好的拥抱变化,快速响应,数据库也会有相对较好的性能

商品表(商品名称、价格、上下架等一些商品基本的信息、商品分类)

 

规格表(主键、规格名称 )

Rocky:

规格值表(规格值ID、规格id、规则值类型、规格默认值)

主键约束一定要加,非空约束必不可少。外键最好不要加,除非是关联极多,业务极其复杂的时候才可以考虑加外键。

规格-分类关联表(商品分类id,规格id)

 

商品-规格关联表(商品id,规格id,规格值ID,规格实际值)

知乎:关于电商网站数据库的设计?

库存表(商品id,数量,价格)

我在思考一个问题,电商网站的数据库设计,主要是商品分类,商品的详情(不同的商品有不同的熟悉,比如衣服有颜色、尺码,然而电脑有CPU、内存、显卡等规格),库存表(一个商家里面某个商品有不同的规格,不同的规格有不同的库存数量),这之间怎么设计。

类似淘宝关于产品详情页的数据库存储是怎么存储的呢?

可能我描述的不是很清楚,我想了解一下这方面改怎么设计,可能有朋友问我,为什么不按照分类吧数据库设计“死”呢,因为易于之后的扩展,我不可能一下子做的很完善,总是慢慢扩展的,所以想这么做。

1,每个产品的 图片数和介绍的段落数都是不固定的,是采用编辑器编辑好之后生成html整个存储到数据库么?不现实吧?

 

  1. 要是以数据库字段存储到话,每个产品的 图片数和介绍的段落数是不固定的,就算设置一个上限,那也会浪费很多字段啊

何明璐:

3.在查询的时候,如果图片和介绍文字是分开存储的,那么在查询之后页面展示的时候是怎么 将某一图片和关于介绍他的问题相匹配的呢

 

刘传双:

首先来说对于这种场景有两种设计方法,这两种方法都能够满足扩展性要求

总体来说

 

1、商品的结构化信息保存在数据库,名称、价格、库存、属性等,当然不是简单的一张表。

  1. 把原有的横表转化为纵表存储属性,即

2、商品的非结构化信息保存成小文件,存储在自主开发的海量小文件系统中,图片和商品描述信息。

产品表:(product_id, product_name, product_class)

3、商品的图片文件id需要存储在数据库或者其他类型的存储的,不一定非要多个字段,这是水平方式,一般把商品的一个图片存储为一条记录,纵向扩展。

产品属性表:(product_id, property_id , property_name , property_value)

4、文档在存储之前,先保存图片,并把文档中<img>的图片src地址替换为小文件系统中的图片路径,就可以了

 

补充一句,不能把存储理解成只有数据库和文件系统,存储有各种类型的,不同的文件系统、各种RDBMS、NoSql存储……

  1. 保持原有横表设计思路,但是弹性字段含义单独元数据表存储

子柳:

产品表:(product_id, product_name, product_class, prop1, prop2, .... propn)

其实几位同事已经回答了,我再从历史的角度做个补充

产品属性含义元数据表

最早这个字段确实是放在数据库里面的,是一个clob字段,存放的就是html的片段。而且当时这个字段跟商品的标题、价格、卖家ID等等是在一个表里面的,性能会受到多大影响是可以想象的。

(product_class , prop1_name ,prop2_name, ..... propn_name)

所以这种方式是注定长久不了的,我在2005年,把这个字段单独分离出来一张表来存放了,这没多少技术含量,当时却给数据库减轻了很大压力,DBA们很感谢我。

 

在2006年以后,淘宝开始大规模的采用缓存,这个字段也放进了缓存里面,于是这又给数据库减轻了很大压力(只有不在缓存里的数据,才去数据库里面读取,读出来就放入缓存了)。

对于两种设计方法,个人理解为

到了2007年,淘宝开发了分布式文件存储系统TFS,于是就彻底的把这个字段请出了数据库,一同请出的还有交易快照这样的大字段信息。

 

a. 对于首页打开就必须要能够快速查询出来的属性,而且这些属性本身各类产品差异不大。而对于差异大的属性基本都是针对特定一个产品查询。可以采用方案1来做。

b. 首页显示产品列表时候就存在要显示出不同产品属性情况,采用方案2来做。当我们处理的是一个product list的时候,由于存在数据表本身的关联场景,用方案1会比麻烦,也影响性能。

/*********************************************************/

goods_common(公共商品表)

 

规格和属性的区别是,规格影响价格,属性不影响价格,在商品分类页的是属性筛选

 

规格名称字段

把规格名称数组序列化后存入这个字段

例如:Array ( [1] => 颜色 ),

key对应的是规格表的id,value对应规格表的名称

key部分是不会变的,value部分是可以被店铺填商品的时候修改

 

规格值字段

把规格名称对应的值数组序列化后存入这个字段

例如:Array ( [1] => Array ( [222] => 蓝色 [224] => 绿色 [225] => 梅红 [226] => 黑色 ) ),

第一维的key对应规格表id,

二维数组的key对应规格值表的id,value对应规格值表的名称

 

商品属性

例如:Array ( [206] => Array ( [name] => 款式 [3050] => 毛衣 ) [207] => Array ( [name] => 材质 [3059] => 棉 ))

一维数组的key对应的是属性表的id,二维数组的name对应属性表的名称,二维数组的第二个元素key对应属性值表id,value对应属性值表的名称

 

商品公共id

商品名称

商品宣传词

商品分类id

商品分类名称————适度冗余,减少关联表

店铺id

店铺名称         ————适度冗余,减少关联表

品牌id

品牌名称

类型id              ————关联类型表,并关联类型下面的属性

商品主图         ————只保存上传后图片的文件名,全路径通过程序拼接,更灵活

商品内容

商品状态         ————0 下架,1 正常

违规原因

商品审核

审核失败原因

商品锁定

商品添加时间

商品上架时间

商品价格

是需求和流程,区分单品。市场价

成本价

折扣

商家自定义编号

运费模版

运费模版名称

是否推荐

是否免运费

是否开具增值税发票

一级地区id

二级地区id

店铺分类id 首尾用,隔开

顶部关联版式

底部关联版式

 

 

 

goods(商品主表)

添加不同规格的商品,生成多条商品信息,sku是不同的,

商品SKUid

是需求和流程,区分单品。商品公共id

商品名称(+规格名称)

商品宣传词

店铺id

店铺名称

商品分类id

商品品牌Id

商品价格

市场价

商家自定义编号

点击数量

销售数量

收藏数量

商品规格序列化,例如:Array ( [222] => 蓝色 )

商品库存

商品主图

商品状态

商品审核状态

商品添加时间

商品编辑时间

一级地区id

二级地区Id

颜色规格id     ————关联商品图片表,展示颜色图片

运费模版id

是否推荐

是否免运费

是否开具增值税发票

店铺分类id 首尾用,隔开

好评星级

评价数量

 

spec (商品规格表)

规格id

规格名称

规格排序

分类id

分类名称

 

spec_value (商品规格值表)

规格值id

规格值名称

规格id

分类id

店铺id     ————不同的店铺,规格值不同

规格颜色

排序

 

attribute(商品属性表)

属性id

属性名称

类型id

属性值列

是否显示

排序

 

attribute_value(商品属性值表)

属性值id

属性值名称

属性id

类型id

属性值排序

 

category(商品分类表)

分类id

分类名称

类型id     ————添加商品时选择分类,根据类型id,类型规格表,关联规格id,取出规格

 

类型名称

父级id

排序

标题

关键字

描述

 

type(商品类型表)

类型id

类型名称

排序

分类id

分类名称

 

type_spec(类型规格关联表)

类型id

规格id

 

goods_image(商品图片表)

商品图片id

商品公共id

店铺id

颜色规格id     ——关联商品表的颜色id,展示在详情页部分

商品图片

排序

是否默认         ——是否是封面上展示的图片

本文由威尼斯发布于jave,转载请注明出处:是需求和流程,区分单品

关键词: