【微服务】149：商品数据结构（一）

学习计划安排如下：

• 这几天的学习才是电商网站的精髓：商品的数据结构分析，目测要花个几天的时间。
• 由简入难依次学习，当然由于我个人的进度问题，导致今天只学了一个商品规格组。

一、商品规格数据结构

前几天学的什么商品分类，商品品牌，都是小儿科，数据结构超级简单。

但是商品的数据结构是比较复杂，如下图：

这是国内某电商网站上的某手机的参数。

这些数据如何存放到数据库中？

前面也说过，写代码前要将数据模型搞清楚：

前端页面上的数据——数据库里的数据表——Java代码中的实体类。

这三者之间的关系搞清楚了，才好写代码。

以前一张数据表就能搞定，现在显然不合适，要设计多张数据表才行，我们逐一分析：

1规格参数和商品分类

上面三张图，分别对应着空调和手机的规格参数，当然参数有很多，我只是截图了一部分。

从中我们能够看出：

• 不同分类下的商品，比如空调和手机，其规格参数是不一样的。
• 相同分类下的商品，比如小米手机和苹果手机，其规格参数是一样的。
• 相同分类下的商品，规格参数一样，但其对应的值是不一样的。

所以规格参数是与商品分类相关联的，并且规格参数名和具体的规则参数值要分开保存。

如果按照传统设计，会采用横表设计：会将上图中的所有规格参数作为数据表列名。

简而言之就是：一条信息，描述所有数据，但是这样会有一个问题就是表的列名会超级多。

而我们采用竖表设计，把规格参数和规格参数值拆分成两张表，联合起来说明规格参数。

2规格参数组设计

从规格参数中我们再次能发现：规格参数是非常多的，所以将其进行了分组。

比如上图中的规格组名

• 主体：入网型号、品牌……等等
• 基本信息：机身长度、机身重量……等等
• 屏幕：屏幕像素，屏幕材质……等等

这样等于是将规格参数再一次进行了垂直细分，同时规格组也是与商品分类相关联。

一个商品分类下有多个规格组，比如手机的规格组有：主体、基本信息、屏幕…等。

3规格参数设计

关于规格参数，也可以做一个分析，当然如果时间充足应该将其对应的业务代码一起讲完的。

但由于学习进度问题只能留待明天编写代码了，先做一个分析：

规格参数值它本身有一个id，同时与商品分类和规格组相关联。

当然实际上规格参数表考虑的更加地全面，还有额外的几个参数：

• umberic：是否为数值类型，true表示数值类型，false表示不是数值类型。
• unit：参数的单位。
• searching：标记是否用作过滤，true表示用于过滤搜索，false表示不用于过滤。
• segments：比如说电池容量其值是一个区间，所以需要做一个说明。

二、规格参数组业务完成

在刘小爱商城后台管理系统中，我们可以找到和规格参数相关的页面。

前端页面具体是如何编写的就不再一一分析了，只说明下其请求相关：

确认请求的四大内容：

• 请求路径：真实路径为spec/group。
• 请求方式：GET请求。
• 请求参数：cid，其直接出现在了路径中。
• 返回值：规格参数组集合。

请求相关确定完成，下面完成代码编写。

第一步确定和规格参数组对应的实体类，这个步骤太简单了，就不赘述了。

第二步Controller层代码：

关于这一层的代码实际上也就对应上和请求相关的四大内容。

注意：因为请求参数是cid，直接出现在请求路径中的，所以使用注解@PathVariable。

返回值即为查询到的规格参数集合。

第三步Service层代码：

因为是单表查询，使用通用mapper即可，mapper层只需要继承对应接口即可。

这就涉及到通用mapper中的知识点了：

如果查询参数不是主键，将参数存放到对应的实体类对象中，再根据对象查询。

查询的结果即为一个集合，如果集合不存在，抛出一个自定义的异常。

第四步在前端页面做一个测试

代码若是没问题，就会出现上述内容，从数据库中查询到了对应的数据并显示。

但是这只是完成了查询操作，还有对应的增删改操作，思路是大同小异的，一般来说查询最常见，新增相对而言复杂一点儿。

以上就是对规格参数组的说明，还有规格参数以及更难的商品属性分析，后续继续学习。

最后

行有不得反求诸己，我是@刘小爱

一个白天上班晚上学习的95后沪漂，不为其它，只为学会自律做好自己，也愿我的每日打卡能给你带来勇气，欢迎点赞关注和评论。