[PHP] B2B2C商品模块数据库设计

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

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

 

kentzhu:

在电子商务里,一般会涉嫌如此多少个词:商品、单品、SPU、SKU

 

简单明了一下,SPU是基准产品单元,区分序列;SKU是库存量单位,区分单品;商品特指与信用社有关的货色,可对应多少个SKU。

 

第一,搞精晓商品与单品的界别。例如,iphone是一个单品,可是在天猫上当很多铺面同时售卖这么些产品的时候,iphone就是一个货物了。

 

商品:天猫叫item,京东叫product,商品特指与企业有关的货色,每个商品有一个商行编码,每个商品下边有三个颜色,款式,可以有多个SKU。

 

SPU = Standard Product Unit
(标准化产品单元),SPU是商品音讯聚合的蝇头单位,是一组可复用、易检索的条件新闻的聚众,该集合描述了一个出品的性状。通俗点讲,属性值、特性相同的货色就足以称之为一个SPU。例如,iphone4就是一个SPU,N97也是一个SPU,那一个与商家非亲非故,与颜色、款式、套餐也毫不相关。

 

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

 

SKU是大体上不可分割的微乎其微存货单元。在行使时要依照不相同业态,差别管
理方式来拍卖。比如一香烟是50条,一条里有十盒,一盒中有20支,那个单位就要根据不一致的急需来设定SKU。

 

老黄的实验室:

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

 

衣服为例:

一款衣服,是一个spu

那款衣裳,有黑白七个颜色,小中大特大多少个尺码,颜色和尺寸就是他的多少个尺码,每个颜色和尺寸排列组合,组成最后的sku。

 

iphone6为例:

iphone6是一个spu

原则1-颜色,包括灰色白色,土豪金

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

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

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

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

 

搜狐:有哪些常见的数据库优化措施?

 

谢龙:

1.善用explain,看看自己写的sql到底要涉及到多少表,多少行,使用了这几个索引,按照那些音信格外的开创索引;

2.善用分裂的仓储引擎,MySQL有八种分裂的仓储引擎,InnoDB,Aria,MEMORY依照须求给分裂的表接纳分裂的蕴藏引擎,比如要辅助transaction的话用InnoDB等;

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

 

惑春秋:

数据库物理层:
1)数据库系统软件应该尽量跟数据文件分置分化存储设备
2)如果可能数据库临时空间、log尽量使用高效存储设备
3)数据文件应该依照具体运用需要分置差距存储设备进步读取作用
4)数据文件使用RAID既保持数据安全又方便质量

数据库逻辑层
1)为数据库system表空间、user表空间、应用表空间分离
最起码user和使用不应该使用系统表空间
只要可能三类表空间应该分在分化物理存储上
2)应用表空间中
表的表空间、索引的表空间也应当分别
3)成立表时应该考虑表的风味
譬如有些表一大半时候是只插入记录很少修改删除
有些表是所有记录平常增、删、改
稍微表唯有少数字段
稍稍表有恢宏字段但大部分时候其中基本上字段为空
有些表数据增进迅猛
稍加表数据常年基本不变
等等
分化特点的表应该在开创时定义区其他发端空间和空中拉长方案
以尽可能让一条记下处于一个总是的大体存储空间升高读取功用
除此以外要制订差别的备份恢复生机和散装整理机制
4)索引不是越来越多越好
而是因表的性状而各异
数码变动频仍的表还应当建立目录定期重建机制
否则索引不但不会革新品质还会下滑品质
5)某些应用常用表比如lookup code之类的
万一可能尽量建在独立的表空间上
并把表空间建在连忙存储设备上

地点那个对SQL Server一类轻量级的数据库也就基本上了
但对于Oracle DB2那种重量级数据库
再有内存管理优化
太久不做时代部分理不清头绪了
尔后想起来能补再补

数据库应用层
本条太多了
首先Modeling要合理
其一太重大
采纳设计不创立再怎么优化、何人来优化也只是死马当活马病

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

 

 

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

例如非空约束,外键约束等。因为自身见状大家商家的DBA在陈设数据库结构的时候都是不加任何自律的,那样对品质的拉长有多大,会不会影响到数码的完整性。新手求大牛解答?

joylisten:

大学派会告知您在筹划的时候把应该有些羁绊都助长

 

而实行派得出的结论是主键一定加,非空约束尽量加,外键最好凭借于程序逻辑,而不是数据库,从而更好的抱抱变化,神速响应,数据库也会有相对较好的质量

 

Rocky:

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

 

今日头条:关于电商网站数据库的统筹?

自家在揣摩一个标题,电商网站的数据库设计,重即使商品归类,商品的详情(区其余货色有差其余熟悉,比如衣服有颜色、尺码,不过电脑有CPU、内存、显卡等标准),库存表(一个合作社里面某个商品有不相同的标准化,不一致的规格有两样的库存数据),这里面怎么设计。

莫不本身叙述的不是很明亮,我想驾驭一下那上头改怎么规划,可能有情侣问我,为啥不根据分类吧数据库设计“死”呢,因为易于之后的增加,我不可能转手做的很完美,总是逐渐增加的,所以想那样做。

 

何明璐:

 

第一来说对于那种气象有三种设计方法,那二种格局都可以满意增添性需要

 

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

产品表:(product_id, product_name, product_class)

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

 

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

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

产品属性含义元数据表

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

 

对于二种设计方式,个人领悟为

 

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,显示在详情页部分

商品图片

排序

是不是默许         ——是还是不是是封面上浮现的图片

相关文章