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

[magicdu]

如题，大家或者大家的公司怎么处理业务逻辑复杂的 SQL 语句呢，用 mybatis 呢？还是干脆舍弃了 SQL 呢，采用其他的方式呢？

[nutting]

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

[pb941129]

django queryset...算 orm 吧

[szq8014]

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

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

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

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

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

[TommyLemon]

@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

[no1xsyzy]

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

[TommyLemon]

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

[zhaogaz]

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

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

[TommyLemon]

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

[TommyLemon]

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

[janus77]

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

[gowk]

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

[passerbytiny]

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

[zjsxwc]

@no1xsyzy

你自己不会用，怪谁

[ghos]

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

[xrlin]

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

[TommyLemon]

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

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

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

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

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

[TommyLemon]

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

[blless]

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

[timepast]

@linbiaye thx,我看下

[TommyLemon]

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