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
|