谷粒商城第九天-对商品服务中所涉及到的表的思考

目录

一、总述

二、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，阐述了其基本含义，与基本属性，销售属性，分类间的关系，另外还对商品服务中所涉及到的表进行简要说明。表设计的思路还是很重要的，要根据具体的业务需要来进行设计。