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

商品图片

排序

是否默认         ——是否是书面上亮的图纸

相关文章