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

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

知乎:产品 SKU 是何等看头?与之有关的还有哪些?

 

kentzhu:

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

 

简简单单明白一下,SPU是条件产品单元,区分连串;SKU是库存量单位,区分单品;商品特指与集团有关的货品,可对应三个SKU。

 

第一,搞掌握商品与单品的界别。例如,iphone是一个单品,不过在Taobao上当很多商店同时出售这个产品的时候,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)成立表时应该考虑表的特色
诸如有些表大部分时候是只插入记录很少修改删除
多少表是所有记录平常增、删、改
稍微表唯有少数字段
稍稍表有雅量字段但大多数时候其中基本上字段为空
有点表数据增长快捷
多少表数据常年基本不变
等等
不等特色的表应该在创制时定义不同的开局空间和空间增长方案
SQL Server,以尽力而为让一条记下处于一个接连的情理存储空间提升读取效率
除此以外要制定不同的备份復苏和零散整理机制
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,映现在详情页部分

货物图片

排序

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

相关文章