+
 新版
2021-11-02 15:11
还是JPA好用
2021-11-02 16:31
sqltoy并不否定jpa,sqltoy本身就是长期使用jpa的情况下补充查询不足的产物,因此sqltoy本身就是JPA+ 超强查询
2021-11-01 14:22
我看出来了,你是来抬杠的
2021-11-01 12:20
你这种方法是挺好的。但是也怕越改越复杂,次数多了完全看不懂了。这个时候还是xml更直观
2021-11-01 10:27
作为一个orm,select count 时剔除最外层的order by不是每个框架应该的么?如果不是,那么mybatis之类的也太令人失望了~
2021-11-01 10:50
order by这种应该属于分页优化的第一层,目前大家都应该已经做了这层优化。但多个with as 时仍然优化不到位。

第二层优化:避免每次都取count查询
第三层优化: 可以并行查询count和记录
第四层优化:利用@fast 先分页后关联
2021-11-01 10:20
你逗我么?都什么年代了,还用xml这种过气的格式~
2021-11-01 10:23
https://my.oschina.net/u/4234377/blog/4305669

看看这个再来说吧,我就知道这年头一定有见xml就反的人
2021-11-01 11:32
我也认为XML没必要。直接把SQL写在代码里不香吗? 下面是一个用Java代替XML的写法示例:
Object[] SQL=[
"select * from order_table t where 1=1 ",
notBlank(" and t.ORDER_ID=", orderId),
notBlank(" and t.status=", status),
" order by ", (status!=null)? "t.status": " t.date ",
pagin(pageNo, 10);
];
其中notBlank和pagin是纯Java方法,比在XML中添加方法更方便,而且无学习负担。
2021-11-01 11:39
项目有简单有复杂,简单的可以这么干,复杂的大段sql写在代码中极其不合适
2021-11-01 11:50
"复杂"要看什么情况,一种是大段大段的sql,但是逻辑非常简单,参数也少,这种情况下用XML、md或Java的长文本块存放可读性比较好。
但是常见的另一种复杂情况是,逻辑非常复杂,参数非常多,经常要修修改改的复杂SQL,直接放在代码中反而是极合适的,因为有些逻辑条件或扩展功能复杂到只能用Java来表达才方便,而且用Java来存放还有一个优点是不象XML需要安装IDE插件才能定位到SQL上。
综上两种情况,如果允许使用Java的文本块(JDK13以上),直接把SQL放在代码中都是胜过放在XML里的
2021-11-01 12:06
这没有什么争议,sqltoy本身就是支持直接传sql和xml中的sqlID,并不是说sql必须且只能用xml写,完全根据自身喜好来决定
2021-11-01 20:46
哈哈,是jsqlbox的作者,还在坚持sql代码化!
2021-11-01 16:51
你这代码里写sql一看就是刚毕业或者刚培训出来的,都什么年代了还在代码里硬编码写sql
2021-11-01 22:59
时代变了,JDK15之后,大段文本写在代码里没啥不好的,SQL就是文本而已。
2021-11-01 11:07
我就喜欢xml自己写原生SQL的感觉。
2021-11-01 16:54
自己无知了,别以为知道个json格式就觉得自己了不起,就觉得xml不适合了,得看场景,json传输数据有优势,xml做配置就是有优势,android开发布局配置,wpf界面布局配置,flutter布局配置都是xml你怕是不知道吧,难道你比人家微软,谷歌还牛呢
回复 @
{{emojiItem.symbol}}
返回顶部
顶部