数据库结构
商品相关的表比较多，而且都是多对多关联
列表查询
先看下界面，可以通过商品名称、商品编码、商品分类、商品的上下架状态和售罄状态查询
这些属性涉及两个表，其中yoshop_goods 包含查询商品的基本属性，但商品和分类分类是多对多关系，要通过 yoshop_goods_category_rel 这个关联表查询
增加一个sqlbuilder节点，根据前端查询的参数组装对应sql
(function(query) {
var {listType = 'all', goodsName='', goodsNo='', categoryId=''} = msg.req.query
var q = query.from("yoshop_goods").where({
"store_id": msg.store_id,
"is_delete": 0
})
if (goodsName) q.where("goods_name", 'like', `%${goodsName}%`)
if (goodsNo) q.where("goods_no", 'like', `%${goodsNo}%`)
if (listType == 'sold_out') q.where("stock_total", 0)
if (listType == 'on_sale') q.where("status", 10)
if (listType == 'off_sale') q.where("status", 20)
if (parseInt(categoryId)) {
q.whereExists(function() {
this.from('yoshop_goods_category_rel')
.whereRaw('yoshop_goods_category_rel.goods_id = yoshop_goods.goods_id')
.where("category_id", categoryId)
})
}
return q
})(query)
因为需要根据每个筛选条件是否传值来拼sql，这里用闭包的方式处理
在处理根据商品分类查询时，用到了exists子查询
保存代码并部署，在界面根据不同条件查询，可以看到后台打印的调试sql和接口返回的数据
但实际上前端代码会报错，因为只返回了列表数据，缺少分页的信息
分页查询
涉及到分页的table，前端需要的数据结构大概是这样的
{
"code": 0,
"message": "success",
"data": {
"list": {
"current_page": 1,
"last_page": 1,
"per_page": 15,
"total": 1,
"data": [
{
"goods_id": 3
"...": "..."
}
]
}
}
}
系统中大量页面都用到了分页查询，我们先建立一个分页查询的子流程
思路很简单
1、先根据查询的sql，把 SELECT 和 FROM 之间的内容替换为 COUNT(*)， 查询出该查询语句命中的总行数
PS：只处理最普遍的情况，没有对性能进行优化，比如去掉 sql 里的 ORDER BY 语句等
msg.topic = msg.topic.trim().replace(/(select)\s+(.*?)\s+(from\s+)(.*)/img, "$1 COUNT(*) AS _count $3 $4")
2、根据记录总数，和每页的查询行数，计算总页数
这里的 msg.paginate 是按前端需要的结构组装的
const {page=1, pagesize = 15} = msg.req.query
const per_page = parseInt(pagesize) || 10
const total = msg.payload[0]._count
msg.paginate = {
current_page: parseInt(page) || 1,
last_page: Math.ceil(total / per_page),
per_page,
total
}
return msg;
3、根据前端传递的page和per_page参数，计算本次查询的数据，起始位置，拼到查询sql后
const {current_page, per_page} = msg.paginate
const offset = (current_page - 1) * per_page
msg.topic = msg.sql + ` LIMIT ${offset}, ${per_page}`
return msg;
4、最后组装返回的数据
商品明细查询
商品明细涉及的表很多，参考最上面示意的er图……
接口返回的结构参考下面截图，基本上和商品关联的信息都需要查询出来了
下面拆解下接口的处理流程
1、首先根据id查询商品信息
2、查询到商品后，就是分别查询关联的图片、分类、服务承诺、规格、sku等数据，并组装到一起返回前端
这里的每个查询都很简单，但每个查询之间没有太大关联，如果按串行的方式，把一大坨拼凑到一起就会很难看。
出于审美，到市场找了个join-wait的插件，该插件每次接收到消息后，会判断是否在等待列表中，如果等待的消息全部到达后，把消息进行合并处理，并发送到下游节点
PS：支持指定消息到达的顺序，支持超时
编排完的流程长这样
小结
1、有一说一，knex还是偏底层，处理复杂的关联查询能力比较弱。类似的场景，截一段用laravel实现的代码，可以直观看到两种方式的差别
后面等有时间了把 knex 换成 Prisma 和 Sequelize 试下
2、从流程编排角度看，node-red某种程度实现了逻辑的所见即所得，至少不需要额外写注释了
