各位的代码里还在用 SQL 语句吗？怎么管理的

JPA,QueryDSL?? 不清楚，我还没有工作。

...不都是封装好或者存储过程然后你只能调用的吗，代码里面直接操作 SQL 比较危险呀

@kawowa 第一次见到用存储过程的!!!!!!

公司不是 java 开发, 所以都是用的 orm 框架. 例如: User.query.... 这样的.
你只需要关注业务就可以了, 具体 sql 是由 orm 自己拼的.

spring boot jpa。
然鹅还是遇到不少需要自己写 sql、hql 的情况

spring data jpa 说错了- -

团队自己做了个数据访问层，基本思路类似 mybatis。把 sql 写在 xml 中。

@kawowa 我这大部分都是复杂查询，其他的修改更新很少

@zgray 这样确实能比较直观的管理 sql，

mybatis 啊，复杂的语句直接扔 xml 里面。

简单的就 spring-data-jpa with Querydsl 了，复杂的还是写 xml 里好点，否则在 Java 文件里拼字符串太难编辑了。

用存储过程，代码拼 sql 是最原始的方式

mybatis 不够吗, 通通都放进了 xml 里

MyBatis + 注解，全部内聚到 DAO 里，也不用涉及 XML

websql 当然是自己写 sql 了

1. ORM 是反模式，是错误的东西，它企图弥合关系数据库和对象之间的鸿沟，但却带来了更复杂的抽象。2. 诸多 ORM 之间的 API 不一致，导致无法重用，既然有了 SQL 这么表达力强又优美的语言，为什么还要把它翻译成 ORM 的方式？仅仅因为你希望用「统一」的语言开发你的软件？ 3. ORM 可能会产生性能问题。综上所述，Hibernate 是垃圾，JPA 是垃圾中的垃圾，我推荐 Mybatis，或者其他基于 JDBC 的轻量级封装库或 Query Builder。

作为数据库开发者我只想劝一句：不要用 ORM ！不要用 ORM ！不要用 ORM ！

@gowk ORM 能解决 90%的场景，提升 90%的开发效率

@gowk 至于性能……性能一下子就优化好了我岂不是要失业了

答楼主：用 querybuilder 管理啊，最经典的设计模式之一！


ps，楼上黑 orm 是什么意思，经典的数据持久化抽象没什么好黑的，这种黑不是坏就是蠢

我们手写 SQL，支撑了一亿多日活。

scala, 纯

fp, 用 doobie 交互数据库, 直接在代码里撸 raw sql.

我们的方案是 mybatis， 简单的 CURD 交给插件，复杂的手写。表结构变了插件直接重新生成一下，插件和手撸的互不干扰。

坚持手写 SQL 一百年不动摇

@tabris17 嗯，大部分 trivial shit code 用用 ORM 也无可厚非

对性能没啥要求的系统，用啥都行，怎么方便怎么来
对性能有要求的只能手写

简单的场景用 JPA 就够了，复杂的 JPA 也支持自定义 SQL 啊。
用 JPA 有个好处不用写 mapper

ORM 性能确实不佳，但是能满足大量的简单的增删改查，开发效率比较高， 复杂查询可以用自定义 SQL 解决。 我司用 .net 平台， 采用的 NHibernate + dapper 的组合。

我司手写复杂 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 脚本，按顺序部署时应用到数据库中。

开发环境中模块对表的读写有管理，不是某个模块想写哪就写哪，想读谁就读谁，但这个在生产环境不检查。

大部分需求都用这个自动化 ORM 库，不需要写代码，逻辑太复杂或对性能要求高的地方就手写 SQL。
它会自动将前端传的 JSON 参数转为 SQL 语句执行并返回结果，
期间自动校验权限、结构、内容，自动防 SQL 注入。
github。com/TommyLemon/APIJSON

@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

@actar
@ltoddy
@skypyb
@gowk
@fuyufjh
@tabris17
@beginor
Hibernate, Spring Data JPA, QueryDSL 表达力都不够强，
除了单表的增删改查，其它复杂一点的，例如 JOIN 写起来比原生的 SQL 还麻烦，
首先是一堆括号，然后 <, >, !=, <=, >= 等符号还得用 lt, gt, ne, lte, gte 等别扭的写法。
Star 都已经被自动化的 APIJSON 超过了。
https://github.com/TommyLemon/APIJSON

我接触下来，真的称得上业务的一般都不存在简单的 CRUD
最起码一定都是连表，左右结合是家常便饭的那种...
这种时候 ORM 简直一无是处

@TommyLemon 括号倒是不用手写，但阅读起来麻烦。

@xy90321
一般的互联网应用还是大量存在简单的 CRUD 和 不是比较复杂但不是很复杂的查询 需求的，用 APIJSON 很合适。
对于一堆需要写 1 屏以上 SQL 才能实现需求的 ERP 项目，还是老老实实写原生 SQL 或 Mybatis 这种接近原生 SQL 的代码吧。

@TommyLemon CRUD 和 比较复杂但不是很复杂的查询

@linbiaye 什么插件？

mybatis+mapper, 爽

@TommyLemon #32 实在话，三表之上的内外连接家常便饭

如果楼主公司的业务有大量定制 sql 语句，还是放 xml 最清晰吧，毕竟分离了。。

写 java 用过 mybatis-plus，还是挺爽的

Python 和 Go 还是用 orm 居多，都还行

JOOQ+SimpleFlatMapper 感觉比 QueryDSL 稍微顺畅一点

就算是现有的 ORM 框架也总会有手写 SQL 的接口

@gowk #16 照你 1、2 的说法，你为什么不直接用 SQl 做开发，更简单？至于 3，设计良好的程序，Hibernate 性能比 Mybatis 以及手写 SQL 高，是不争的事实，说话前请做好调查。还有，Mybatis 也是 ORM。

手写 SQL

@xy90321 #33 你需要了解一下领域驱动设计。

@kawowa 存储过程，如果切库怎么办？

公司在用 mybaits plus + mybaits 增删改全部通过 mybaits plus 查找自己写 sql 放到 xml 里面

作为开发人员 SQL 还是有必要深入掌握，哪怕用的是 ORM，脑海里也要知道生成的 SQL 是怎样，在一些查询稍微复杂的场景，很多时候的性能问题往往都是慢查询所致。

PHP 数据取出来存数组，字段是哪些都不知，IDE 也就更智障了，所以 ORM 在 PHP 里面还是很好用，这时候就比较羡慕你们强类型的。不过，有些 ORM 把事情弄得很复杂，我也不太喜欢（对，我说的就是 Laravel ），只要简单的 Query Builder 和数据 mapping 就行了。

互联网业务，特别的信息业务我接触的比较多，大多数时候直接到数据这一步大多都是简单的 CURD，可以不连表就不连表，能上缓存就上缓存的。重复零碎的 SQL 很多的，手写并不是很好管理，可读性也不好。真需要手写的，也多用 SQL shop 之类的统一管理调用，直接在业务里写 SQL，我不太喜欢。

@timepast idea 的插件 https://github.com/linbaiye/yobatis.git

前几天看到一歪果仁的统计调查里用 mybatis 的少得可怜，基本是 hibernate、jpa

不要拼接 SQL
现在的注入还少吗

复杂查询不用 SQL 用 ORM 大概会累死吧

@gowk 老哥有道理，我看很多人简直为了分层而分层

@kingwl 手写 SQL 不等于拼接 SQL。

mybaits
xml

mybatis。。。我们团队的老产品技术栈还停留在原始 JDBC 的阶段。。

jdbcTemplate 手撸 sql

ORM

ORM + SQL
对于负责情况下的数据库操作，没办法只能用 SQL 去处理，大部分实在 ORM 下工作
关于 SQL 语句的管理，其实没有太规范的方式，我们都是直接用类似 ini 文件格式的方式去管理的~

感觉 orm 不适合对象套对象的复杂面向对象关系，搞了以后性能会下降很多。如果简单了呢又有点鸡肋，比较尴尬

django queryset...算 orm 吧

不知道为啥 Hibernate 这么招黑，很多用 Mybatis 开发发现 sql 生成太麻烦，然后加代码生成器插件，还有的用动态的 mapper，为了性能再配个缓存，这样搞和 Hibernate 有多大区别。。这不是屠龙少年的故事么？ 0.0

对于 [简单的 CRUD] 来说 Hibernate 开发效率很高啊，而且和缓存深度结合的，为啥不尝试一下 Hibernate，当你拒绝一个东西的时候你就少了一条路 0.0

像那种银行啊、考勤啊那种随便一个查询就关联 N 个表的查询业务场景 mybatis 还是非常适合的。

对于那种 cud 都喜欢写 sql 的推荐去写 php，一杆子捅到数据库？（逃

这么想控制每一行代码每一个细节，肯定是处于自己对于技术的不自信~（我也是不自信，希望以后能做到大剑无锋

@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

@zjsxwc #20 ORM 反数据库操作，把所有东西一股脑给你，然后让你自己丢弃，凭空浪费数据库计算资源和带宽资源。
我不排除有一两个做得好的（对代码静态分析出后续需要什么，或者动态猜测这一处调用后续需要什么），但我为什么要花那么多时间在各种不同语言不同接口的 ORM 中找到一个可以用的？

@szq8014 对的，针对不同的场景选择合适的工具就好。可以看下我上面的回答

其实我不太懂，舍弃 sql 用啥？用 redis 之类的么？还是用别的？存储过程不算 sql ？

还有就是有啥可管理的，要管理啥？

@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 支持下吧 ^_^

@no1xsyzy
“把所有东西一股脑给你，然后让你自己丢弃，凭空浪费数据库计算资源和带宽资源。”
这就是 ORM 库没有封装好的结果，用 APIJSON 就能很简单直接地指定每张表的字段，
自动解析生成的 SQL 里 SELECT 的就不是 * , 而是 "@column": "id,name" 对应的 `id`,`name` 了。

最常用的就 mybatis jpa 啊，不过有自研的一套轻量级框架，用 freemarker 就行了

@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.

@gowk #71 ORM is:Object Relational Mapping. 一瓶不满扳平咣当。

@no1xsyzy

你自己不会用，怪谁

@TommyLemon 那不是重新发明了一个 json 版的 sql。。。。

歪个楼，如果没有 orm，做 query caching 不是不方便了，直接使用 database 的 query caching ？。

@ghos 可以这么理解。
有人问过 “前端为什么不直接发送 sql 到后端更简单直接”

我的回答是：
解析 SQL 语法，再校验权限、结构、内容，最后再转回 SQL，
不说性能问题，真要这么好搞业内也应该有不错的开源方案了。

而且 SQL 不能直观地反映返回 JSON 的数据结构，
APIJSON 就能做到看请求知结果，所求即所得。

APIJSON 的 提取字段、远程函数 功能也不是 SQL 方案能方便地实现的。
还有 自动加注释、自动生成封装请求 JSON 的代码，用 SQL 方案实现也很困难，甚至根本不可能准确地实现。

为什么要用 APIJSON ？或者 APIJSON 有什么用？
https://github.com/TommyLemon/APIJSON/wiki

@TommyLemon APIJSON 是提供了 自动化的权限控制、数据和结构校验、自动防 SQL 注入 的。

反正代码里面查出来的数据也不能直接用，还不是得转换成对象，orm 不用白不用，还能防止低端开发人员的 sql 被注入。业务都是看场景的，查询多上个 redis 不比你各种优化省事

@linbiaye thx,我看下

@blless
对的，缓存能解决大部分性能问题，复杂的 SQL 也很难维护，
只有真的是那种非常复杂的查询，各种 JOIN、子查询、case 一起用，代码在 1 屏以上的才需要手写 SQL。
可以看下我上面的回答，APIJSON 是一个自动化的 ORM 库，不用后端写代码，Star 已超 Hibernate, JPA 等。

@TommyLemon #68 楼 和 #32 楼

楼上疯狂打广告真的辛苦了

ORM 方便啊，API 都可以直接抽象出来，性能以后可以慢慢优化

简单的增删改查就直接 EF Core，方便快捷，复杂的，就直接 Dapper 手撸 SQL 或者存储过程

@TommyLemon 你的项目出发点很好，可是这个用 star 数来和其他项目做比较性是不恰当的吧！ issues 数少的可怜说明用的人太少，做贡献的也太少了，现在哪个公司不是在追赶业务速度，你这个项目任重而道远

@linbiaye #50 2.1.2 从 git 上下载下来，无法加载配置，win 10 + idea 2018.2.5

手写 sql

@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 改一下数据或结构就行。

@Arcy 方便+我 qq 么 Mjg3MDgwOTQ1Cg==

@TommyLemon
Star 虽然不代表使用率，但也能在比较大的程度上反映 Repo 在开源社区的受欢迎程度，可以看下这个趋势图
https://www.timqian.com/star-history/#TommyLemon/APIJSON&hibernate/hibernate-orm

@gowk 说的这么绝对呀 各有千秋吧 虽然我也比较偏 mybatis

你可以用下，我写的
https://github.com/gsralex/gdata
决心要把 sql 从 java 代码中消除，个人觉得是错误的想法。用 mybatis 的 xml 来替代 java 控制 sql，就好比你把原来的鼠标去掉，换用 thinkpad 的指点杆，你要知道 xml 表达能力很弱，完全不适合在里面加入 ifelse 的语句。

手撸了几个类拼接 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();
```

select,insert,update 单表 JA 挺爽, 带条件的分页查询，只有 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 秒几十条

@xipushi Hibernate 有 batchInsert 方法，另外如果你开启了事务，几千条之内的插入，它有可能会自动缓存然后批量插入。

JPA 的动态查询（其实还是 Hibernate 的）要用到 Criteria API，或者 Spring 提供的 JpaSpecificationExecutor<T>，但是比较重量级，需要先理解对象型数据（而非关系型数据）的查询原理（跟 SQL 或 HQL 完全不一样）。

有一点很关键，如果脑袋还有 SQL 的概念，那么用 JPA/Hibernate 回很吃力。Hibernate 的合理分工应该是，Java 人员只负责定义实体类，Hibernate 框架负责自动生成表，DBA 负责优化数据库和映射关系。当然，如果已经能达到上面的分工了，那么异步编程、事件编程、领域驱动设计这些概念估计也已经用上了。

@passerbytiny 刚看了下 QueryDSL，动态分页查询，感觉还是搞事。

我说的 MySql 的批量 insert, 不是批量提交。是 insert table()values(),(),(), 一条 SQL 语句插入多条数据，batchInsert 是多条 insert 语句, 数据库的特性，批量提交比一条语句要慢点。

Hibernate 的合理分工是理想状态，现实中我没看到只用 HQL, 不用 native SLQ。还是要有 SQL 概念，不然前人留下的代码你就看不懂了。

不用 sql 用什么？二进制格式协议速度是最快的

@TommyLemon
看你推广 apijson 挺久了，不过你能说下你这玩意比 Spring Data Rest 有声明绝对优势？

@V2XEX 不用写代码

@TommyLemon
为什么要用 APIJSON ？前后端 10 大痛点解析
github.com/TommyLemon/APIJSON/wiki