商城 商品模块 数据库 表设计

要实现一个商城，对于商品模块中的数据库表设计不懂，主要是：相同类别的产品的产品参数相同，不同类别的不同，这里就不懂要怎么设计了，所以上网找几篇博客了解

---

---

什么是SPU、SKU、ARPU

这是一篇存档性笔记，我自己存档一下对这3个词的理解。如果你已经明了了这3个词的意思，请直接忽略之

首先，搞清楚商品与单品的区别。例如，iphone是一个单品，但是在淘宝上当很多商家同时出售这个产品的时候，iphone就是一个商品了。

商品：淘宝叫item，京东叫product，商品特指与商家有关的商品，每个商品有一个商家编码，每个商品下面有多个颜色，款式，可以有多个SKU。

SPU = Standard Product Unit （标准化产品单元）

SPU是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息的集合，该集合描述了一个产品的特性。通俗点讲，属性值、特性相同的商品就可以称为一个SPU。

例如，iphone4就是一个SPU，N97也是一个SPU，这个与商家无关，与颜色、款式、套餐也无关。以化妆品为例，下图是拍拍商城给出的SPU信息：

在商品信息电子化过程中，商品的特性可以由多个“属性及对应的属性值对”进行描述。“属性及对应的属性值对”完全相同的商品，可以抽象成为一个SPU。同 时，这些“属性及对应的属性值对”也在SPU中固化下来，逐步标准化。基于SPU的商品信息结构，可以实现丰富的应用，比如商品信息与资讯、评论、以及其 它SPU的整合。

P.s：从这个意义上讲，我认为比较购物的产品库以SPU为标准来建立是最合适的。

SKU=stock keeping unit(库存量单位)

SKU即库存进出计量的单位， 可以是以件、盒、托盘等为单位。在服装、鞋类商品中使用最多最普遍。 例如纺织品中一个SKU通常表示：规格、颜色、款式。

也有人解释说SKU就是库存的最小单位，在服装行业，正常情况是“单款单色单码”，国内品牌有把“单款单色”当做一个SKU、也有把“单款”的几个色当一个SKU、也有把一块面料的几个个款式当一个SKU,这些都是误读。

同时，引申出另外一个概念：SKC：单款、单色。如果一定要打比方的话：SKC是一个桔子，SKU是一瓣桔子，但不管怎么说，一个桔子是桔子，一瓣桔子也是桔子。

不过，SKU是物理上不可分割的最小存货单元。在使用时要根据不同业态，不同管 理模式来处理。比如一香烟是50条，一条里有十盒，一盒中有20支，这些单位就要根据不同的需要来设定SKU。比如仓储批发式大卖场，一定是按照一箱来设 定的。普通大卖场一定是按照条来设定的。烟酒专卖店一定是按照盒来设定的。过去上海等地的街边小店一定是按一支来设定的。这样一支就是烟的最小零售单位。 但要根据自己的业态和服务模式来设定。

P.s:关于什么是SKU、SKC，可以参考阿福先生的这篇博客。

【总结一下】：SPU是标准化产品单元，区分品种；SKU是库存量单位，区分单品；商品特指与商家有关的商品，可对应多个SKU。

ARPU=Average Revenue Per User(每用户平均收入)

ARPU注重的是一个时间段内运营商从每个用户所得到的利润。因此，高端的用户越多，ARPU越高。在这个时间段里，从运营商的运营情况来看，ARPU值高说明利润高，这段时间效益好。

原文地址：http://www.ikent.me/blog/3017

---

PHP商城 商品模块 数据库 表设计

表关系:
分类表 <= 商品表 <= SKU表(库存表)
分类表 <= 属性名 <= 属性值
商品表 <= 商品和属性关系表 => 属性名|属性值

业务逻辑:
1.同一商品不同SKU库存和售价不同.
2.不同类型的商品具有不同的属性名和属性值(如汽车和服饰),所以属性需要支持后期添加和维护.
3.在某个商品分类下通过属性筛选商品.
4.商家某件商品的销量统计,该件商品内几个不同SKU的销量统计.
5.更多…

分类表:
(商品分类编号, 分类名称, 父分类编号)
(1, 男装, 0)
(2, 裤子, 1)
(3, 外套, 1)
(4, 内裤, 1)
(5, 袜子, 1)

商品表:
(商品编号, 商品名称, 商品分类编号, 卖家编号, SPU销量, 评论数)
(1, '裤子名', 2, 1, 0)
(2, '外套名', 3, 1, 0)
(3, '内裤名', 4, 1, 0)
(4, '袜子名', 5, 1, 0)

SKU表(库存表):
(SKU编号, 商品编号, SKU属性, 价格, 库存, SKU销量)
(1, 1, [1:1,2:3], 99, 400, 0) 其中 [1:1,2:3] 表示 "颜色为黑色,尺码为X"
(2, 1, [1:1,2:4], 99, 200, 0) 其中 [1:1,2:4] 表示 "颜色为黑色,尺码为XL"
(3, 1, [1:2,2:3], 99, 300, 0) 其中 [1:2,2:3] 表示 "颜色为白色,尺码为X"
(4, 1, [1:2,2:4], 99, 100, 0) 其中 [1:2,2:4] 表示 "颜色为白色,尺码为XL"
上面只列出商品1这个分类的4个SKU.

属性名:
(属性名编号, 属性名, 商品分类编号, 父属性编号)
(1, 颜色, 2, 0)
(2, 尺码, 2, 0)
(3, 品牌, 2, 0)
上面只列出裤子这个分类的3个属性名.

属性值:
(属性值编号, 属性值, 属性名编号)
(1, 黑色, 1)
(2, 白色, 1)
(3, X,  2)
(4, XL, 2)
(5, 七匹狼, 3)
(6, 九牧王, 3)
上面只列出裤子这个分类的6个属性值.

商品和属性关系表:
(自增编号, 商品编号, 属性名编号, 属性值编号)
(1, 1, 1, 1) 商品1颜色为黑色
(2, 1, 1, 2) 商品1颜色为白色
(3, 1, 2, 3) 商品1尺码为X
(4, 1, 2, 4) 商品1尺码为XL
上面只列出商品1的4个属性关系.

商品和属性筛选表:
(商品编号, 商品具有的属性值编号)
(1, [1,2,3,4])
用SQL全文检索实现筛选.
如:
select * from 商品表 
inner join 商品和属性筛选表 
on 商品表.商品编号 = 商品和属性筛选表.商品编号
where 商品表.商品分类编号 = 2 
and 商品和属性筛选表.商品具有的属性值编号 MATCH '1 3'
order by 商品表.评论数 DESC LIMIT 10 OFFSET 20;

商品搜索表:
(商品编号, 商品标题和内容)
(1, [无需词典,二元分词])
用SQL全文检索实现搜索.

里面有这么一些表结构设计思想:
名值: id, name, value (用于实现自定义字段如属性的存储)
父子: id, pid (用于实现关系树如分类和子分类的存储)
其中”名值”的思想应该就是EAV(Entity-Attribute-Value)实体属性值模型思想.
留意过WordPress数据表的也会看到类似设计:
wp_postmeta(meta_id,post_id,meta_key,meta_value)
wp_commentmeta(meta_id,comment_id,meta_key,meta_value)
wp_usermeta(umeta_id,user_id,meta_key,meta_value)
wp_options(option_id,option_name,option_value,autoload)
“父子”存储无限极分类:
wp_term_taxonomy(term_taxonomy_id,term_id,taxonomy,parent)

上面提到的无需词典的二元分次算法示例:

function cws($str) {
//找出字符串中的英文单词和数字
if(preg_match_all('%[A-Za-z0-9_-]{1,}%', $str, $matches)) {
$arr = $matches[0];
}
//以非中文(中文包括简体和繁体)进行正则分割
$sections = preg_split('%[^\x{4e00}-\x{9fa5}]{1,}%u', $str);
foreach($sections as $v) {
//注意:foreach中多次正则匹配会降低性能
switch(true) {
case ($v === ''): continue; break;
case (mb_strlen($v, 'UTF-8') < 3): $arr[] = $v; break;
case (preg_match_all('%[\x{4e00}-\x{9fa5}]%u', $v, $matches)):
//前后俩俩组合,实现冗余分词.
//如"中国好声音"将被分词为: 中国 国好 好声 声音
$size = count($matches[0]);
for($i = 0; $i <= $size-2; $i++) {
$word = '';
for($j = 0; $j < 2; $j++) {
$word .= $matches[0][$i+$j]; //echo $i.' '.$j.' '.$matches[0][$i+$j]."\n";
}
$arr[] = $word; //echo "\n";
}
break;
}
}
return array_unique($arr);
}


© 著作权归作者所有
分类：工作日志 字数：1050
标签： 商品库 商城 SKU SQL 数据库设计

原文链接：https://my.oschina.net/eechen/blog/857845

---