[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)

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

产品表：（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，展示在详情页部分

商品图片

排序

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