数据库结构

商品相关的表比较多，而且都是多对多关联

image.png

列表查询

先看下界面，可以通过商品名称、商品编码、商品分类、商品的上下架状态和售罄状态查询
这些属性涉及两个表，其中yoshop_goods 包含查询商品的基本属性，但商品和分类分类是多对多关系，要通过 yoshop_goods_category_rel 这个关联表查询

image.png

增加一个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和接口返回的数据

image.png

但实际上前端代码会报错，因为只返回了列表数据，缺少分页的信息

分页查询

涉及到分页的table，前端需要的数据结构大概是这样的

{
    "code": 0, 
    "message": "success", 
    "data": {
        "list": {
            "current_page": 1, 
            "last_page": 1, 
            "per_page": 15, 
            "total": 1, 
            "data": [
                {
                    "goods_id": 3
                    "...": "..."
                }
            ]
        }
    }
}

系统中大量页面都用到了分页查询，我们先建立一个分页查询的子流程

image.png

思路很简单
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图……
接口返回的结构参考下面截图，基本上和商品关联的信息都需要查询出来了

image.png

下面拆解下接口的处理流程

image.png

1、首先根据id查询商品信息

image.png

2、查询到商品后，就是分别查询关联的图片、分类、服务承诺、规格、sku等数据，并组装到一起返回前端

image.png

这里的每个查询都很简单，但每个查询之间没有太大关联，如果按串行的方式，把一大坨拼凑到一起就会很难看。
出于审美，到市场找了个join-wait的插件，该插件每次接收到消息后，会判断是否在等待列表中，如果等待的消息全部到达后，把消息进行合并处理，并发送到下游节点
PS：支持指定消息到达的顺序，支持超时

image.png

编排完的流程长这样

image.png

小结

1、有一说一，knex还是偏底层，处理复杂的关联查询能力比较弱。类似的场景，截一段用laravel实现的代码，可以直观看到两种方式的差别
后面等有时间了把 knex 换成 Prisma 和 Sequelize 试下

image.png

2、从流程编排角度看，node-red某种程度实现了逻辑的所见即所得，至少不需要额外写注释了