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

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

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

 

kentzhu:

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

 

简易驾驭一下,SPU是原则产品单元,区分体系;SKU是库存量单位,区分单品;商品特指与商店有关的货色,可对应多少个SKU。

 

第一,搞了然商品与单品的界别。例如,iphone是一个单品,可是在Tmall上当很多集团同时发售这几个产品的时候,iphone就是一个货品了。

 

货物:Tmall叫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,体现在详情页部分

货物图片

排序

是否默认         ——是不是是封面上展现的图形

网站地图xml地图