这是一个创建于 2206 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，大家或者大家的公司怎么处理业务逻辑复杂的 SQL 语句呢，用 mybatis 呢？还是干脆舍弃了 SQL 呢，采用其他的方式呢？
 |
1
actar 2018-11-11 14:58:37 +08:00 via Android  1
JPA,QueryDSL?? 不清楚，我还没有工作。
|
 |
2
kawowa 2018-11-11 14:58:54 +08:00 via Android 1
...不都是封装好或者存储过程然后你只能调用的吗，代码里面直接操作 SQL 比较危险呀
|
 |
4
ltoddy 2018-11-11 15:06:06 +08:00 1
公司不是 java 开发, 所以都是用的 orm 框架. 例如: User.query.... 这样的.
你只需要关注业务就可以了, 具体 sql 是由 orm 自己拼的. |
 |
5
skypyb 2018-11-11 15:11:53 +08:00 via Android 1
spring boot jpa。
然鹅还是遇到不少需要自己写 sql、hql 的情况 |
|
6
skypyb 2018-11-11 15:12:24 +08:00 via Android
spring data jpa 说错了- -
|
 |
7
zgray 2018-11-11 15:14:46 +08:00 via iPhone 1
团队自己做了个数据访问层，基本思路类似 mybatis。把 sql 写在 xml 中。
|
 |
10
linbiaye 2018-11-11 15:23:44 +08:00 1
mybatis 啊，复杂的语句直接扔 xml 里面。
|
 |
11
sutra 2018-11-11 15:35:41 +08:00 1
简单的就 spring-data-jpa with Querydsl 了，复杂的还是写 xml 里好点，否则在 Java 文件里拼字符串太难编辑了。
|
 |
12
dszhblx 2018-11-11 15:48:48 +08:00 via iPhone
用存储过程，代码拼 sql 是最原始的方式
|
 |
13
Raymon111111 2018-11-11 16:00:29 +08:00
mybatis 不够吗, 通通都放进了 xml 里
|
 |
14
qiyuey 2018-11-11 16:06:01 +08:00
MyBatis + 注解，全部内聚到 DAO 里，也不用涉及 XML
|
 |
15
duan602728596 2018-11-11 16:13:45 +08:00 via iPhone
websql 当然是自己写 sql 了
|
 |
16
gowk 2018-11-11 16:23:37 +08:00 14
1. ORM 是反模式，是错误的东西，它企图弥合关系数据库和对象之间的鸿沟，但却带来了更复杂的抽象。2. 诸多 ORM 之间的 API 不一致，导致无法重用，既然有了 SQL 这么表达力强又优美的语言，为什么还要把它翻译成 ORM 的方式？仅仅因为你希望用「统一」的语言开发你的软件？ 3. ORM 可能会产生性能问题。综上所述，Hibernate 是垃圾，JPA 是垃圾中的垃圾，我推荐 Mybatis，或者其他基于 JDBC 的轻量级封装库或 Query Builder。
|
 |
17
fuyufjh 2018-11-11 17:31:45 +08:00
作为数据库开发者我只想劝一句：不要用 ORM ！不要用 ORM ！不要用 ORM ！
|
 |
20
zjsxwc 2018-11-11 17:47:38 +08:00 via Android 1
答楼主：用 querybuilder 管理啊，最经典的设计模式之一！
ps，楼上黑 orm 是什么意思，经典的数据持久化抽象没什么好黑的，这种黑不是坏就是蠢 |
 |
21
xhinliang 2018-11-11 19:24:39 +08:00
我们手写 SQL，支撑了一亿多日活。
|
 |
22
SabaPing 2018-11-11 19:46:57 +08:00
scala, 纯
fp, 用 doobie 交互数据库, 直接在代码里撸 raw sql. |
|
23
linbiaye 2018-11-11 19:48:11 +08:00
我们的方案是 mybatis， 简单的 CURD 交给插件，复杂的手写。表结构变了插件直接重新生成一下，插件和手撸的互不干扰。
|
 |
24
atcdef 2018-11-11 19:49:01 +08:00
坚持手写 SQL 一百年不动摇
|
 |
26
alamaya 2018-11-11 20:23:50 +08:00
对性能没啥要求的系统，用啥都行，怎么方便怎么来
对性能有要求的只能手写 |
 |
27
Aidenboss 2018-11-11 20:37:03 +08:00
简单的场景用 JPA 就够了，复杂的 JPA 也支持自定义 SQL 啊。
用 JPA 有个好处不用写 mapper |
 |
28
beginor 2018-11-11 20:43:48 +08:00 via Android
ORM 性能确实不佳，但是能满足大量的简单的增删改查，开发效率比较高， 复杂查询可以用自定义 SQL 解决。 我司用 .net 平台， 采用的 NHibernate + dapper 的组合。
|
 |
29
dawncold 2018-11-11 20:46:24 +08:00 1
我司手写复杂 SQL，但也不至于连 insert into 也是手写，对数据库操作有简单封装，主要是对结果进行封装：获取一行、获取一列、获取某行的某列、执行任意 SQL，如果有特别需要 insert into 也是手写，不使用 ORM，这样很直观，心里有底吧。
对结果简单封装后用起来和 ORM 差不多，比如获取一个订单： ```python purchase = db().get('SELECT * FROM purchase WHERE id=%(purchase_id)s', purchase_id=123) print(purchase.shopper_id) print(purchase.sales_channel_id) ``` 等等读取操作和用 object 的感觉一样，但如果要更新 purchase 则需要写 SQL： ``` db().execute('UPDATE purchase SET processed_at=CURRENT_TIMESTAMP WHERE id=%(purchase_id)s', purchase_id=123) ``` 获取一些订单： purchases = db().list('SELECT * FROM purchase WHERE created_at>=CURRENT_DATE') for purchase in purchases: print(purchase.id) 获取订单某个字段： shopper_id = db().get_scalar('SELECT shopper_id FROM purchase WHERE id=%(purchase_id)s', purchase_id=123) 获取订单 ids： purchase_ids = db().list_scalar('SELECT id FROM purchase WHERE created_at>=CURRENT_DATE') 对数据库的变动写 migration 脚本，按顺序部署时应用到数据库中。 开发环境中模块对表的读写有管理，不是某个模块想写哪就写哪，想读谁就读谁，但这个在生产环境不检查。 |
 |
30
TommyLemon 2018-11-11 23:32:47 +08:00
大部分需求都用这个自动化 ORM 库，不需要写代码，逻辑太复杂或对性能要求高的地方就手写 SQL。
它会自动将前端传的 JSON 参数转为 SQL 语句执行并返回结果， 期间自动校验权限、结构、内容，自动防 SQL 注入。 github。com/TommyLemon/APIJSON |
|
31
TommyLemon 2018-11-11 23:38:03 +08:00 1
@TommyLemon
前端传一个 JSON： { "User": { "id": 82001 }, "[]": { "count": 10, "page": 1, "Comment": { "userId@": "User/id", "@order": "date-" } } } 后端完全自动化解析，不用写代码。 1.自动生成 SELECT * FROM User WHERE id = 82001 LIMIT 1 OFFSET 0 2.自动生成 SELECT * FROM Comment WHERE userId = ${User.id} ORDER BY date DESC LIMIT 10 OFFSET 10 |
|
32
TommyLemon 2018-11-11 23:47:19 +08:00
|
 |
33
xy90321 2018-11-11 23:59:24 +08:00
我接触下来，真的称得上业务的一般都不存在简单的 CRUD
最起码一定都是连表，左右结合是家常便饭的那种... 这种时候 ORM 简直一无是处 |
|
34
TommyLemon 2018-11-12 00:01:54 +08:00
@TommyLemon 括号倒是不用手写，但阅读起来麻烦。
|
|
35
TommyLemon 2018-11-12 00:05:31 +08:00 1
@xy90321
一般的互联网应用还是大量存在简单的 CRUD 和 不是比较复杂但不是很复杂的查询 需求的，用 APIJSON 很合适。 对于一堆需要写 1 屏以上 SQL 才能实现需求的 ERP 项目，还是老老实实写原生 SQL 或 Mybatis 这种接近原生 SQL 的代码吧。 |
|
36
TommyLemon 2018-11-12 00:05:57 +08:00
@TommyLemon CRUD 和 比较复杂但不是很复杂的查询
|
 |
38
BBCCBB 2018-11-12 08:37:25 +08:00
mybatis+mapper, 爽
|
 |
39
liuxey 2018-11-12 08:46:46 +08:00
|
 |
40
tairan2006 2018-11-12 08:47:02 +08:00
写 java 用过 mybatis-plus，还是挺爽的
Python 和 Go 还是用 orm 居多，都还行 |
 |
41
lj3lj3 2018-11-12 09:03:34 +08:00
JOOQ+SimpleFlatMapper 感觉比 QueryDSL 稍微顺畅一点
|
 |
42
micean 2018-11-12 09:06:50 +08:00
就算是现有的 ORM 框架也总会有手写 SQL 的接口
|
 |
43
passerbytiny 2018-11-12 09:11:05 +08:00 1
@gowk #16 照你 1、2 的说法，你为什么不直接用 SQl 做开发，更简单？至于 3，设计良好的程序，Hibernate 性能比 Mybatis 以及手写 SQL 高，是不争的事实，说话前请做好调查。还有，Mybatis 也是 ORM。
|
 |
44
salamanderMH 2018-11-12 09:11:53 +08:00
手写 SQL
|
|
45
passerbytiny 2018-11-12 09:12:28 +08:00
@xy90321 #33 你需要了解一下领域驱动设计。
|
 |
46
Chenamy2017 2018-11-12 09:15:30 +08:00
@kawowa 存储过程，如果切库怎么办？
|
 |
47
zrrd 2018-11-12 09:18:11 +08:00
公司在用 mybaits plus + mybaits 增删改全部通过 mybaits plus 查找自己写 sql 放到 xml 里面
|
 |
48
binge 2018-11-12 09:27:14 +08:00
作为开发人员 SQL 还是有必要深入掌握，哪怕用的是 ORM，脑海里也要知道生成的 SQL 是怎样，在一些查询稍微复杂的场景，很多时候的性能问题往往都是慢查询所致。
|
 |
49
jswh 2018-11-12 09:27:21 +08:00
PHP 数据取出来存数组，字段是哪些都不知，IDE 也就更智障了，所以 ORM 在 PHP 里面还是很好用，这时候就比较羡慕你们强类型的。不过，有些 ORM 把事情弄得很复杂，我也不太喜欢（对，我说的就是 Laravel ），只要简单的 Query Builder 和数据 mapping 就行了。
互联网业务，特别的信息业务我接触的比较多，大多数时候直接到数据这一步大多都是简单的 CURD，可以不连表就不连表，能上缓存就上缓存的。重复零碎的 SQL 很多的，手写并不是很好管理，可读性也不好。真需要手写的，也多用 SQL shop 之类的统一管理调用，直接在业务里写 SQL，我不太喜欢。 |
|
50
linbiaye 2018-11-12 09:29:12 +08:00
|
 |
51
chocotan 2018-11-12 09:29:26 +08:00
前几天看到一歪果仁的统计调查里用 mybatis 的少得可怜，基本是 hibernate、jpa
|
 |
52
kingwl 2018-11-12 09:37:37 +08:00
不要拼接 SQL
现在的注入还少吗 |
 |
53
xschaoya 2018-11-12 09:41:02 +08:00 via Android
复杂查询不用 SQL 用 ORM 大概会累死吧
|
 |
56
hzw94 2018-11-12 09:50:49 +08:00
mybaits
xml |
 |
57
Variazioni 2018-11-12 09:54:40 +08:00
mybatis。。。我们团队的老产品技术栈还停留在原始 JDBC 的阶段。。
|
 |
58
nekoneko 2018-11-12 10:03:56 +08:00
jdbcTemplate 手撸 sql
|
 |
59
balamiao 2018-11-12 10:18:20 +08:00
ORM
|
 |
60
visonme 2018-11-12 10:20:52 +08:00
ORM + SQL
对于负责情况下的数据库操作，没办法只能用 SQL 去处理，大部分实在 ORM 下工作 关于 SQL 语句的管理，其实没有太规范的方式，我们都是直接用类似 ini 文件格式的方式去管理的~ |
 |
61
nutting 2018-11-12 10:22:46 +08:00
感觉 orm 不适合对象套对象的复杂面向对象关系，搞了以后性能会下降很多。如果简单了呢又有点鸡肋，比较尴尬
|
 |
62
pb941129 2018-11-12 10:34:45 +08:00
django queryset...算 orm 吧
|
 |
63
szq8014 2018-11-12 10:52:01 +08:00
不知道为啥 Hibernate 这么招黑，很多用 Mybatis 开发发现 sql 生成太麻烦，然后加代码生成器插件，还有的用动态的 mapper，为了性能再配个缓存，这样搞和 Hibernate 有多大区别。。这不是屠龙少年的故事么？ 0.0
对于 [简单的 CRUD] 来说 Hibernate 开发效率很高啊，而且和缓存深度结合的，为啥不尝试一下 Hibernate，当你拒绝一个东西的时候你就少了一条路 0.0 像那种银行啊、考勤啊那种随便一个查询就关联 N 个表的查询业务场景 mybatis 还是非常适合的。 对于那种 cud 都喜欢写 sql 的推荐去写 php，一杆子捅到数据库？（逃 这么想控制每一行代码每一个细节，肯定是处于自己对于技术的不自信~（我也是不自信，希望以后能做到大剑无锋 |
|
64
TommyLemon 2018-11-12 10:58:57 +08:00
@binge 说的很对，SQL 肯定是要掌握的，不仅在于方便优化性能，还在于方便使用 Navicat 等数据库工具来调试。
@liuxey @passerbytiny @micean @visonme @xschaoya 一般 ORM 对不是很复杂的查询都能做到一定程度的优化的，能提高性能下限，但也会拉低上限。 所以不是很复杂的 SQL 用 ORM 做很合适，太复杂的还是手写 SQL 针对性更好。 APIJSON 的自动化 JOIN，自动解析生成的 SQL 和手写的 除了多了引号外几乎没有区别， 至于连表的数量也没有限制，3 张表不算什么。 { "[]": { "count": 5, "join": "&/User/id@,</Comment/momentId@", "Moment": {}, "User": { "id@": "/Moment/userId", "@column": "id,name" }, "Comment": { "momentId@": "/Moment/id" } } } 会自动解析为 SELECT `Moment`.*,`User`.`id`,`User`.`name`,`Comment`.* FROM `Moment` INNER JOIN `User` ON `User`.`id` = `Moment`.`userId` LEFT JOIN `Comment` ON `Comment`.`momentId` = `Moment`.`id` LIMIT 5 OFFSET 0 创作不易，GitHub 右上角点 Star 支持下吧 ^_^ github.com/TommyLemon/APIJSON |
 |
65
no1xsyzy 2018-11-12 11:00:48 +08:00
@zjsxwc #20 ORM 反数据库操作，把所有东西一股脑给你，然后让你自己丢弃，凭空浪费数据库计算资源和带宽资源。
我不排除有一两个做得好的（对代码静态分析出后续需要什么，或者动态猜测这一处调用后续需要什么），但我为什么要花那么多时间在各种不同语言不同接口的 ORM 中找到一个可以用的？ |
|
66
TommyLemon 2018-11-12 11:01:24 +08:00
@szq8014 对的，针对不同的场景选择合适的工具就好。可以看下我上面的回答
|
 |
67
zhaogaz 2018-11-12 11:02:15 +08:00
其实我不太懂，舍弃 sql 用啥？用 redis 之类的么？还是用别的？存储过程不算 sql ？
还有就是有啥可管理的，要管理啥？ |
|
68
TommyLemon 2018-11-12 11:07:02 +08:00
@no1xsyzy
@nutting @visonme Hibernate 这种对于稍微复杂一点的关联查询写法都比较麻烦，代码不够直观，一般非单表的 CRUD 确实不如手写 SQL。 APIJSON Star 已经超过它了，并且对于简单的 CRUD、比较复杂但不是非常复杂的查询 就支持得很好，非常直观： { "[]": { "count": 5, "join": "&/User/id@,</Comment/momentId@", "Moment": {}, "User": { "id@": "/Moment/userId", "@column": "id,name" }, "Comment": { "momentId@": "/Moment/id" } } } 会自动解析为 SELECT `Moment`.*,`User`.`id`,`User`.`name`,`Comment`.* FROM `Moment` INNER JOIN `User` ON `User`.`id` = `Moment`.`userId` LEFT JOIN `Comment` ON `Comment`.`momentId` = `Moment`.`id` LIMIT 5 OFFSET 0 APIJSON 目前已实现： 大体功能：增删改查、分页查询、统计与验证、注册登录、模糊搜索、结构校验、角色及操作权限校验、数据保护、远程函数调用等 操作方式：增、删、改、查、调用远程函数 操作对象：单个对象、可关联的多个对象、数组等 请求方法：GET,HEAD,GETS,HEADS,POST,PUT,DELETE 请求结构：{Table:{...}}、{Table0:{...},Table1{...},Table2:{...}...}、{"[]":{Table:{...}}}、{"[]":{Table0:{...},Table1{...},"Array0[]":{...},...}}等各种组合和嵌套 返回结构：对应请求结构的各种 JSON 结构。 功能符号： "key[]":{} // 查询数组 "key{}":[] // 匹配选项范围 "key{}":"<=10;length(key)>1..." // 匹配条件范围 "key()":"function(arg0,arg1...)" // 远程调用函数 "key@":"key0/key1.../targetKey" // 引用赋值 "key$":"%abc%" // 模糊搜索 "key~":"^[0-9]+$" // 正则匹配 "key%":"2018-01-01,2018-10-01" // 连续范围 "key+":[1] // 增加 /扩展 "key-":888.88 // 减少 /去除 "name:alias" // 新建别名 "@column":"id,sex,name" // 返回字段 "@group":"userId" // 分组方式 "@having":"max(id)>=100" // 聚合函数 "@order":"date-,name+" // 排序方式 "@schema":"sys" // 集合空间 "@database":"PostgreSQL" // 跨数据库 "@role":"LOGIN" // 访问角色 详细说明见通用文档中的 [功能符]( https://github.com/TommyLemon/APIJSON/blob/master/Document.md#3.2) 创作不易，GitHub 右上角点 Star 支持下吧 ^_^ |
|
69
TommyLemon 2018-11-12 11:09:50 +08:00
@no1xsyzy
“把所有东西一股脑给你，然后让你自己丢弃，凭空浪费数据库计算资源和带宽资源。” 这就是 ORM 库没有封装好的结果，用 APIJSON 就能很简单直接地指定每张表的字段， 自动解析生成的 SQL 里 SELECT 的就不是 * , 而是 "@column": "id,name" 对应的 `id`,`name` 了。 |
 |
70
janus77 2018-11-12 11:13:50 +08:00
最常用的就 mybatis jpa 啊，不过有自研的一套轻量级框架，用 freemarker 就行了
|
|
71
gowk 2018-11-12 11:14:45 +08:00
@passerbytiny MyBatis is SQL centric. It heps you calling SQL statements and mapping results (tables) to object trees. The main benefit is that it is *not* an ORM.
|
|
72
passerbytiny 2018-11-12 11:22:08 +08:00
@gowk #71 ORM is:Object Relational Mapping. 一瓶不满扳平咣当。
|
 |
74
ghos 2018-11-12 11:24:34 +08:00
@TommyLemon 那不是重新发明了一个 json 版的 sql。。。。
|
 |
75
xrlin 2018-11-12 11:38:14 +08:00
歪个楼，如果没有 orm，做 query caching 不是不方便了，直接使用 database 的 query caching ？。
|
|
76
TommyLemon 2018-11-12 11:46:46 +08:00
@ghos 可以这么理解。
有人问过 “前端为什么不直接发送 sql 到后端更简单直接” 我的回答是： 解析 SQL 语法，再校验权限、结构、内容，最后再转回 SQL， 不说性能问题，真要这么好搞业内也应该有不错的开源方案了。 而且 SQL 不能直观地反映返回 JSON 的数据结构， APIJSON 就能做到看请求知结果，所求即所得。 APIJSON 的 提取字段、远程函数 功能也不是 SQL 方案能方便地实现的。 还有 自动加注释、自动生成封装请求 JSON 的代码，用 SQL 方案实现也很困难，甚至根本不可能准确地实现。 为什么要用 APIJSON ？或者 APIJSON 有什么用？ https://github.com/TommyLemon/APIJSON/wiki |
|
77
TommyLemon 2018-11-12 11:47:43 +08:00
@TommyLemon APIJSON 是提供了 自动化的权限控制、数据和结构校验、自动防 SQL 注入 的。
|
 |
78
blless 2018-11-12 12:02:13 +08:00 via Android
反正代码里面查出来的数据也不能直接用，还不是得转换成对象，orm 不用白不用，还能防止低端开发人员的 sql 被注入。业务都是看场景的，查询多上个 redis 不比你各种优化省事
|
|
80
TommyLemon 2018-11-12 12:17:50 +08:00
@blless
对的，缓存能解决大部分性能问题，复杂的 SQL 也很难维护， 只有真的是那种非常复杂的查询，各种 JOIN、子查询、case 一起用，代码在 1 屏以上的才需要手写 SQL。 可以看下我上面的回答，APIJSON 是一个自动化的 ORM 库，不用后端写代码，Star 已超 Hibernate, JPA 等。 |
|
81
TommyLemon 2018-11-12 12:20:56 +08:00
@TommyLemon #68 楼 和 #32 楼
|
 |
82
buhi 2018-11-12 12:56:58 +08:00 1
楼上疯狂打广告真的辛苦了
|
 |
83
kslr 2018-11-12 13:20:39 +08:00
ORM 方便啊，API 都可以直接抽象出来，性能以后可以慢慢优化
|
 |
84
GiantHard 2018-11-12 13:44:53 +08:00 via Android
简单的增删改查就直接 EF Core，方便快捷，复杂的，就直接 Dapper 手撸 SQL 或者存储过程
|
 |
85
ohoh 2018-11-12 13:59:17 +08:00
@TommyLemon 你的项目出发点很好，可是这个用 star 数来和其他项目做比较性是不恰当的吧！ issues 数少的可怜说明用的人太少，做贡献的也太少了，现在哪个公司不是在追赶业务速度，你这个项目任重而道远
|
 |
87
zhangalong69 2018-11-12 14:12:44 +08:00
手写 sql
|
|
88
TommyLemon 2018-11-12 14:46:19 +08:00
@ohoh 使用率确实没有 Hibernate 高，毕竟它从 07 年开源到现在都快 12 年了，APIJSON 才 2 年多一点。
哪个开源库的 star/issue 等不是从 0 开始的呢？ 如果都是你这种想法，Hibernate，Mybatis，OKHTTP，Vue.js 等非 大厂 /名人 出的开源库也不会流行起来了。 Hibernate 都关掉 issue 了。 你可以说 issue 数量多反映使用率高， 我也可以认为 issue 数量相对少体现 bug 少及简单易用， 才没有大量的 issue 来提交 bug、咨询使用方法 /文档 等。 越是追赶业务，越要用简单易用、快速实现功能的工具啊， Hibernate 等一堆 ORM 库都是要针对每个接口写一堆 封装对象 或 注解传 SQL、写 XML 的代码， APIJSON 提供了自动化的 CRUD 接口个，就能做到不写代码， 前端传一个 JSON，后端自动转 SQL 并连接数据库执行，然后返回结果， 当需求更改时，也不用后端修改或新增代码，前端把 JSON 改一下数据或结构就行。 |
|
90
TommyLemon 2018-11-12 15:05:16 +08:00
@TommyLemon
Star 虽然不代表使用率，但也能在比较大的程度上反映 Repo 在开源社区的受欢迎程度，可以看下这个趋势图 https://www.timqian.com/star-history/#TommyLemon/APIJSON&hibernate/hibernate-orm |
 |
92
gsralex 2018-11-12 15:21:28 +08:00
你可以用下，我写的
https://github.com/gsralex/gdata 决心要把 sql 从 java 代码中消除，个人觉得是错误的想法。用 mybatis 的 xml 来替代 java 控制 sql，就好比你把原来的鼠标去掉，换用 thinkpad 的指点杆，你要知道 xml 表达能力很弱，完全不适合在里面加入 ifelse 的语句。 |
 |
93
xiangyuecn 2018-11-12 15:47:15 +08:00
手撸了几个类拼接 sql 语句发给数据库执行，这种不知道算不算手写 sql
``` //读取数据 FieldRead read=new FiledRead(Table.User); read.Long("id"); read.String("name"); read.Date("time") //生成：select top 100 id,name from userTable where 1=1 order by id desc read.List(100,new SQL().Cmd("1=1 order by id desc"));//[{id:123,name:"name",time:123456789},...100] //生成：select top 1 id,name from userTable where id=123 read.One(new SQL().Cmd("id=").Long(RequestUserID));//{id:123,name:"name",time:123456789} //修改数据 FieldSave save=new FieldSave(Table.User); save.Long("id",newUID()); save.String("name","来搞我啊"); save.Date("time", Now()) //save.Update(new SQL().Cmd("id=").Long(123)); //生成：insert into userTable(id,name,time) values(123,'transform 搞你妹','8102-11-12 15:45') save.Insert(); ``` |
 |
94
xipushi 2018-11-12 16:02:32 +08:00
select,insert,update 单表 JPA 挺爽, 带条件的分页查询，只有 Example.of 用着爽
select * from table where a in(1,2,3) and b in(2,3,4) limit 1,10, 条件是动态的，谁知道 JPA 怎么做得比较爽？这种还是拼 SQL 爽 Hibernate 怎么用 MySql 批量插入语法？ MySql 原生语法 1 秒 insert 几千条，Hibernate 1 秒几十条 |
|
95
passerbytiny 2018-11-12 17:07:26 +08:00
@xipushi Hibernate 有 batchInsert 方法，另外如果你开启了事务，几千条之内的插入，它有可能会自动缓存然后批量插入。
JPA 的动态查询（其实还是 Hibernate 的）要用到 Criteria API，或者 Spring 提供的 JpaSpecificationExecutor<T>，但是比较重量级，需要先理解对象型数据（而非关系型数据）的查询原理（跟 SQL 或 HQL 完全不一样）。 有一点很关键，如果脑袋还有 SQL 的概念，那么用 JPA/Hibernate 回很吃力。Hibernate 的合理分工应该是，Java 人员只负责定义实体类，Hibernate 框架负责自动生成表，DBA 负责优化数据库和映射关系。当然，如果已经能达到上面的分工了，那么异步编程、事件编程、领域驱动设计这些概念估计也已经用上了。 |
|
96
xipushi 2018-11-12 18:48:59 +08:00
@passerbytiny 刚看了下 QueryDSL，动态分页查询，感觉还是搞事。
我说的 MySql 的批量 insert, 不是批量提交。是 insert table()values(),(),(), 一条 SQL 语句插入多条数据，batchInsert 是多条 insert 语句, 数据库的特性，批量提交比一条语句要慢点。 Hibernate 的合理分工是理想状态，现实中我没看到只用 HQL, 不用 native SLQ。还是要有 SQL 概念，不然前人留下的代码你就看不懂了。 |
 |
97
feverzsj 2018-11-12 19:10:49 +08:00
不用 sql 用什么？二进制格式协议速度是最快的
|
 |
98
V2XEX 2018-11-12 19:19:53 +08:00
@TommyLemon
看你推广 apijson 挺久了，不过你能说下你这玩意比 Spring Data Rest 有声明绝对优势？ |
|
99
TommyLemon 2018-11-12 19:24:47 +08:00
@V2XEX 不用写代码
|
|
100
TommyLemon 2018-11-12 19:25:32 +08:00
|
Select Language