当前位置: 首页 > news >正文

C#转java的最好利器easy-query就是efcore4j sqlsugar4j freesql4j

数据库模型

image

点击查看实体代码

案例

查询用户信息和最早开户的银行卡信息

通过模型我们可以清晰的看到SysUser和BankCard是一对多的关系,eq如何实现这种一对多的数据返回呢?

使用临时对象返回

var list = easyEntityQuery.queryable(SysUser.class)

.select(user -> {

//定义最早开户的银行卡

SysBankCardProxy firstBankCard = user.bankCards().orderBy(bankCard -> bankCard.openTime().asc()).first();

return Select.DRAFT.of(

user.id(),

user.name(),

firstBankCard.code(),

firstBankCard.type(),

firstBankCard.openTime(),

firstBankCard.bank().name()

);

}).toList();

生成的sql

SELECT t.`id` AS `value1`, t.`name` AS `value2`, t3.`code` AS `value3`, t3.`type` AS `value4`, t3.`open_time` AS `value5`

, t4.`name` AS `value6`

FROM `t_sys_user` t

LEFT JOIN (

SELECT t1.`id`, t1.`uid`, t1.`code`, t1.`type`, t1.`bank_id`

, t1.`open_time`, ROW_NUMBER() OVER (PARTITION BY t1.`uid` ORDER BY t1.`open_time` ASC) AS `__row__`

FROM `t_bank_card` t1

) t3

ON t3.`uid` = t.`id`

AND t3.`__row__` = 1

INNER JOIN `t_bank` t4 ON t4.`id` = t3.`bank_id`

查询用户至少有5张储蓄卡且没有信用卡的用户信息和对应的第4张储蓄卡信息

分解条件

要先找出用户至少有5张储蓄卡

要找出用户没有信用卡

要返回用户信息

额外返回用户的第4张储蓄卡信息

//新创建一个dto用来接收而不是使用临时对象

@Data

@EntityProxy

public class UserDTO2 {

private String id;

private String name;

private String thirdCardType;

private String thirdCardCode;

private String thirdCardBankName;

}

List<UserDTO2> list = easyEntityQuery.queryable(SysUser.class)

.where(user -> {

//用户至少有三张储蓄卡

user.bankCards().where(c -> c.type().eq("储蓄卡")).count().gt(4L);

//用户没有信用卡

user.bankCards().where(c -> c.type().eq("信用卡")).none();

})

.select(user -> {

SysBankCardProxy thirdCard = user.bankCards().orderBy(bankCard -> bankCard.openTime().asc()).element(3);

return new UserDTO2Proxy()

.id().set(user.id())

.name().set(user.name())

.thirdCardType().set(thirdCard.type())

.thirdCardCode().set(thirdCard.code())

.thirdCardBankName().set(thirdCard.bank().name());

}).toList();

最终生成的sql

SELECT t.`id` AS `id`, t.`name` AS `name`, t5.`type` AS `third_card_type`, t5.`code` AS `third_card_code`, t6.`name` AS `third_card_bank_name`

FROM `t_sys_user` t

LEFT JOIN (

SELECT t3.`id`, t3.`uid`, t3.`code`, t3.`type`, t3.`bank_id`

, t3.`open_time`, ROW_NUMBER() OVER (PARTITION BY t3.`uid` ORDER BY t3.`open_time` ASC) AS `__row__`

FROM `t_bank_card` t3

) t5

ON t5.`uid` = t.`id`

AND t5.`__row__` = 4

INNER JOIN `t_bank` t6 ON t6.`id` = t5.`bank_id`

WHERE (

SELECT COUNT(*)

FROM `t_bank_card` t1

WHERE t1.`uid` = t.`id`

AND t1.`type` = '储蓄卡'

) > 4

AND NOT EXISTS (

SELECT 1

FROM `t_bank_card` t2

WHERE t2.`uid` = t.`id`

AND t2.`type` = '信用卡'

LIMIT 1

)

什么你看不懂sql?没关系直接丢给ai让他帮我们看看

image

看来ai还是很懂sql的嘛

聪明的肯定又发现了盲点,你这边生成了两个子查询sql,导致整体sql性能偏弱是否有好的解决方案呢

隐式group,eq提供了子查询合并我们又叫他groupJoin或者隐式group,那么应该怎么做呢,基本上什么代码都不需要动,只需要加一行配置即可

List<UserDTO2> list = easyEntityQuery.queryable(SysUser.class)

//增加这行配置

.configure(s -> s.getBehavior().add(EasyBehaviorEnum.ALL_SUB_QUERY_GROUP_JOIN))

.where(user -> {

//用户至少有三张储蓄卡

user.bankCards().where(c -> c.type().eq("储蓄卡")).count().gt(4L);

//用户没有信用卡

user.bankCards().where(c -> c.type().eq("信用卡")).none();

})

.select(user -> {

SysBankCardProxy thirdCard = user.bankCards().orderBy(bankCard -> bankCard.openTime().asc()).element(3);

return new UserDTO2Proxy()

.id().set(user.id())

.name().set(user.name())

.thirdCardType().set(thirdCard.type())

.thirdCardCode().set(thirdCard.code())

.thirdCardBankName().set(thirdCard.bank().name());

}).toList();

再来看看我们生成的sql

SELECT t.`id` AS `id`, t.`name` AS `name`, t5.`type` AS `third_card_type`, t5.`code` AS `third_card_code`, t6.`name` AS `third_card_bank_name`

FROM `t_sys_user` t

LEFT JOIN (

SELECT t1.`uid` AS `uid`

, COUNT(CASE

WHEN t1.`type` = '储蓄卡' THEN 1

ELSE NULL

END) AS `__count2__`

, COUNT(CASE

WHEN t1.`type` = '信用卡' THEN 1

ELSE NULL

END) <= 0 AS `__none3__`

FROM `t_bank_card` t1

GROUP BY t1.`uid`

) t2

ON t2.`uid` = t.`id`

LEFT JOIN (

SELECT t3.`id`, t3.`uid`, t3.`code`, t3.`type`, t3.`bank_id`

, t3.`open_time`, ROW_NUMBER() OVER (PARTITION BY t3.`uid` ORDER BY t3.`open_time` ASC) AS `__row__`

FROM `t_bank_card` t3

) t5

ON t5.`uid` = t.`id`

AND t5.`__row__` = 4

INNER JOIN `t_bank` t6 ON t6.`id` = t5.`bank_id`

WHERE IFNULL(t2.`__count2__`, 0) > 4

AND IFNULL(t2.`__none3__`, true) = true

好的我们再把sql交给ai重新开启一个会话看看他会怎么回答

image

很好ai再次证明了easy-query的准确性,且easy-query再次证明了他在OLAP中秒杀所有其他ORM

最后的最后我非常感谢您能看到这边我相信eq绝对是你不二的orm选择

http://www.cnnetsun.cn/news/16422.html

相关文章:

  • Spring AOP场景3——接口防抖(附带源码)
  • 黑客技术水深!普通人不要随便碰
  • AI建议的C++基础入门顺序
  • 35、使用 Ansible 部署脚本化服务器环境
  • 13、文件操作与命令全解析
  • 第32课 PCB布局的常用操作命令介绍
  • 终极修复指南:彻底解决Atmosphere固件2168-0002启动错误
  • 第一章——办公自动化之Word报告自动生成:解放双手,高效创作
  • 压电材料的d33(纵向压电应变常数)测试流程及影响因素
  • 中烟创新连续两年被认定为国家级科技型中小企业
  • s4cmd完整指南:终极高性能Amazon S3命令行工具
  • 开题报告不是“过关文档”,而是“学术项目启动书”——Paperzz AI开题报告功能深度拆解:从选题模糊到框架清晰,它如何把你的“研究冲动”翻译成“可执行的科研计划”?
  • 1996-2025年政府采购合同公告明细数据
  • 分布式应用框架Microsoft Orleans - 2、动手实践:构建你的第一个Microsoft Orleans应用程序
  • MAC电脑如何开发淘晶驰串口屏
  • Java 中 new 一个对象的过程是怎么样的?
  • 从规则引擎到大模型:文档生成技术的十年进化与现在的最佳实践
  • AI客户端终极指南:多平台支持与工作区管理快速上手
  • 安全审查--跨站请求伪造--Fetch Metadata防护模式
  • uni-app x封装request,统一API接口请求
  • 4大维度解析DeepLX与官方API:技术实战与成本效益终极评测
  • 本地 AI 服务难共享?TRAE SOLO+cpolar 轻松打破局域网枷锁
  • 助力金融信创与云原生转型,DeepFlow 排障智能体和可观测性建设实践
  • 靠谱的模板网站建设哪家好
  • PuLID技术深度解析:重新定义人物身份定制的新范式
  • SGLang结构化生成语言:重塑大模型工具调用的新范式
  • Windows Insider免登录终极指南:轻松获取预览版更新
  • FluidNC运动控制固件:重新定义ESP32 CNC设备的智能控制
  • 【光照】Unity[PBR]环境光中的[漫反射]
  • 39、NFS与网络路由管理:配置、问题诊断及参数调优