目录
一、总述
二、spu、sku、规格参数、销售属性之间的关系理解
三、相关表设计
1. 属性表
2. 基本属性分组表
3. 分组-基本属性关系表
4. spu基本属性值表
5. spu详情信息表
6. spu评论表
7. 商品sku值表
8. sku详情表
9. sku图片表
10. 分类表
11. 品牌表
12. 分类-品牌关系表
13. spu图片表
14. spu基本信息描述表
四、总结
一、总述
我们知道,所有的表,都是通过分析实际需求,设计出来的。
那我们先想一下这里的商品服务有哪些需求:
其实最主要的就是涉及到商品的信息,暂且还不说支付、商品库存、什么的,就着重的说商品信息,肯定涉及到商品的分类、品牌、规格参数、销售参数等信息,这是自然而然就能想出来的
那么到底有哪些业务呢?其实回想我们在网上购物就知道
1. 在商品搜索页面,可以查找对应的商品
这里可以按照商品的分类、品牌、价格等进行搜索
2. 查看商品的详情
就是查看商品的更加详细的信息,比如说商品的各项参数,图文介绍等
3. 最终选择要购买的规格
最终选择合适的一种规格进行购买
4. 收到商品之后可以对商品进行评论
大体就是这样,这是与商品最为紧密的一些业务,所以被划分到商品服务下面。
当然商城项目的核心就是围绕商品展开的,除了上述的核心的商品外,还有许多由商品衍生出来的其他业务,比如说购买商品之后的订单业务、商品的采购库存业务、商品所捆绑的优惠卷业务、会员业务等,这些都是由商品这个核心东西来派生出来的。
今天我就来着重的说一下这个商品。其实之前就做过商品的分类、品牌管理的功能了,只是一些很简单的增删改查,业务也是很简单,也就没有过于的去分析表了。
但是从今天开始,要进行一些有关关于平台属性相关的功能开发了,涉及到商品的分组、商品的规格参数、商品的销售属性。这些业务都不是很简单,通常不是单表操作了,涉及到多表的操作。
首先第一步当然是理解好各表的含义,各表之间的关系。
二、spu、sku、规格参数、销售属性之间的关系理解
首先先来理解下商品服务中重要的两个概念:spu和sku
其实很简单。
spu就是商品,就是单纯的一种商品,不涉及到具体的商品下的某一款,其实也就是最先购物时脑子里面所想的,最先想到的当然是,我这次到底时需要买一件什么东西,比如我今天需要去买一部手机,需要去买一台电视机,需要买一台空调等等...这就是对应一个spu
但是随后在真正买的时候,通常需要指定好我到底需要买这件商品的什么规格的,比如说手机有许多的内存规格供我们进行选择,电视机就有许多的尺寸大小供我们进行选择,这其实就对应一个sku
其实spu和sku就好比是Java中类和对象的关系,spu就是一个类,只是商品本身。而sku则是这个类下面的具体的一个对象,具体的一个规格。
那么spu和sku现在简单的理解了一下,那与规格参数还有销售属性之间又有什么关系呢?
先来说一下,规格参数和销售到底是什么?、
规格参数就是当我们查看商品的详情的时候,下面的规格参数详情,手机的话,就有电池容量,拍照像素,手机分辨率等规格参数,如图:
规格前面有其对应的分组:
而销售属性,则是真正买的时候所选的具体规格,如图:
那么spu与sku和规格参数还有销售属性有什么联系呢?
spu和规格参数还有图文信息绑定在一起,也就是说一个spu不同的sku下的规格参数还有图文信息都是一样的,其实不仅如此,通常即使不是同一个spu,也就是不是同一件商品,规格参数也是那些东西,当然图文信息变了,其实规格参数大致都一样,这么说吧,即使不同的品牌,其这些规格参数都差不多,只不过可能是少了某些属性或者是多了某些属性,而其实也就是手机这一分类下,规格参数都差不多,所以规格参数和三级分类绑定在一起,既然规格参数都差不多,规格参数的上一级:分组信息也是差不多的。
上面那么多话总结起来就是:
一个分类下面有着多个spu,但是这多个spu的规格参数基本一样,分组也基本一样
一个spu下面有着多个sku,一个sku就是选定了多个销售属性的值的一种组合,例如一台手机有3中颜色,有3种内存,那么就一共有9种sku
就是一个spu下面有多个sku
三、相关表设计
1. 属性表
规格属性还有销售属性存在这张表
有个时候基本属性是可以检索的,比如手机的cpu,所以提供可检索字段,提供可选值列表,还有所属分类的id字段
2. 基本属性分组表
就是基本属性的前面一个组,所以和基本属性差不多,表结构差不多
也是提供一个分类id的字段
因为无论是分组还是基本属性,一个分类下面有多个,比如手机下面有很多分组,基本信息,屏幕信息啥的,也有很多基本属性,在一个分组下面就有许多基本属性了,所以都放上一个分类id字段
有的人可能会想,既然我分组都知道是属于哪个分类下面了,基本属性又在这个分组下面,那我不也就自然的知道基本属性在哪个分类下面吗?为什么在基本属性表中还要放上这个分类id字段呢?
其实这就是属于冗余设计,记得别人说过这么一句话,要想作数据库设计,第一步就是摒弃数据库设计三范式,当然这有点夸张了,其实三范式确实也就是为了减少冗余而存在的这么一套法则,但是为了减少冗余而将表进行拆分,查的时候就需要进行联表查,效率不高。
因此还是保留了分类id字段,这是为了方便以后的基本属性那里直接可以看到所属分类,而不必再去通过分组表查到分类id,提高了效率,这种冗余字段在数据库中很常见,得习惯。
3. 分组-基本属性关系表
分组和基本属性之间是属于多对多的关系,因此需要第三张表-关系表
4. spu基本属性值表
这个没什么好说的,虽然现在有了其属性,但是真正的值,就需要新的一张表来记录了。这里存了属性id和属性名称,属性名称也是冗余字段
5. spu详情信息表
上面的商品基本属性值表,只是给出了spuid,至于spu也就是商品的详细信息没有,要获取详细信息,比如描述,品牌,所属分类等信息,就需要spu详细信息表
6. spu评论表
保存着一件商品的评论信息,包含用户、评论内容、点赞数、回复数等信息
7. 商品sku值表
这个就保存着商品的sku下的各个属性的值,比如说1号sku下面的颜色属性什么值,1号下面的版本属性什么值
也就是存放所有的sku再细分的销售属性值,其实sku编号只有各个销售属性值的乘积个数,但是还要细分属性值到底是多少,就多了
8. sku详情表
这张表就是每个sku的详情,比如说这种套餐下面的标题,描述,价格,默认图片等信息
9. sku图片表
存放着一个sku下面的多种图片
上面这些是主要的表还有一些表
比如说:
10. 分类表
11. 品牌表
12. 分类-品牌关系表
13. spu图片表
14. spu基本信息描述表
四、总结
主要是讲了商品服务中两个重要的概念:spu和sku,阐述了其基本含义,与基本属性,销售属性,分类间的关系,另外还对商品服务中所涉及到的表进行简要说明。表设计的思路还是很重要的,要根据具体的业务需要来进行设计。