select
s.client_id,
s.package_id,
p.products as pp,
s.products as sp
from (
# grouped subscribed products
select
client_id,
package_id,
group_concat(product_id order by product_id) as products
from subscriptions where package_id is not null
group by client_id, package_id) as s
inner join (
# grouped package products
select
package_id,
group_concat(product_id order by product_id) as products
from package_products
group by package_id) as p
on p.package_id = s.package_id where p.products <> s.products
order by s.client_id
2条答案
按热度按时间qvsjd97n1#
这不是毫无意义的。这在一定程度上取决于您是否在团队环境中工作,还有谁可能需要维护它,以及他们对编写sql查询的适应程度。请注意,knex可以完成的许多事情也可以通过直接数据库驱动程序来完成,因此对于许多技术选择,它归结为个人/团队偏好和易于维护。
即使您从未使用过查询生成器,knex也提供了:
根据目前的情况,配置相对简单
NODE_ENV
连接/池管理易于参数化
轻松的交易
易于迁移和播种
为什么不用
.raw
? 好吧,这是品尝者的选择,而查询生成器并不适合所有人。不过,query builder的粉丝会告诉你:当您不处理一堆原始sql时,在数据库后端之间迁移会更容易
许多人认为knex语法更容易阅读,因为能够合理理解javascript承诺链的人可能比那些喜欢使用sql的人多
它往往比较紧凑
它提供了一定级别的名称/语法安全性(如果您使用的是typescript,还提供了transfile-time类型安全性和编辑器支持)
.raw
.查询生成器也非常适合于组合,因此如下所示:
这是一个精心设计的示例,但在处理不那么琐碎的需求时,它可以非常有表现力。
voase2hg2#
我知道这篇文章有点老,但我同意混合方法。在某些情况下,查询生成器语法为正在编写的“错误”查询提供了良好的反馈,这是非常好的。
另一方面,我有一些查询,我认为使用生成器编写会变得太冗长,所以我使用
.raw
. 下面是一个我认为在.raw
格式。我当然可以使用构建器,但我发现使用嵌套选择更容易掌握原始sql。我还创建了一个抽象类来简化为一个微型orm。
这允许我使用以下方法创建模型: