复杂的业务 SQL 大家依然坚持用 ORM 还是原生拼装的？

缓存和注入解决起来不麻烦吗

为啥不 ORM 呢……多省事儿，还有闭包嵌套拼不出来的复杂 SQL 吗？

我用的 ORM，感觉比拼 SQL 更难维护，更难理解。

得看用什么语言了，ruby 我用 orm，其他语言我用 sql builder

orm 什么 sql 拼不了啊...

你应该说反了, 简单的随便用那个都可以, 复杂的 sql 跟复杂的正则一样, 敲的时候一时爽, 过两天来看已经是路人, 只能说爱过

需要写复杂的 sl 才能实现功能，说明系统设计有问题

orm 已经是政治正确了么……

那个, 上面说 SQL 简单的同学看下这个: http://assets.en.oreilly.com/1/event/27/High%20Performance%20SQL%20with%20PostgreSQL%20Presentation.pdf

有 CTE 的 SQL 是图灵完全的...

还要加上 OVER (PARTITION BY ... ) 这个语句才是图灵完全. 这个语句今天才看到...

@springmarker 拼接 SQL 难道就意味着不能用变量绑定了？

优先 orm 吧 复杂的话着重优化建模，性能敏感场景再裸写 sql

@zhy0216 然而大家使用的 mysql 并没有 CTE

在我的项目中如果涉及到复杂的业务，而在整个项目中又需要采用一些设计方法，比如 DDD,那这样我会有限考虑 ORM，当然 ORM 不是万能的，很多复杂的查询还是需要采用原生的 SQL，而现在大多数的 ORM 框架也支持原生 SQL 操作。

就楼主的问题，我反而觉得很多简单的应用应该考虑原生 sql 而不是 ORM

从项目角度考虑的话，主要是看维护人员的技能树

有的人工作内容就只是 CRUD，用 ORM 就足够了，根本接触不到复杂的系统，甚至认为系统复杂是设计的问题，而不是业务本身就复杂。这些人遇到真正复杂的业务时，会怎样应付，我十分清楚。

另外，就算是 mysql，也早就支持服务端的 prepare 语句，哪还用拼接。

我认为要看业务的需求，如果是模块化的业务，再复杂也能用 orm 拼装，但是如果不是通用，而是非常特殊的业务，可以用 sql，

受教了，感觉 ORM 还是有点用起来别扭，而且需要一定的学习成本。SQL 写的太久了，总觉得 SQL 解决一切问题！

@Ouyangan 连 5-10 张表，写个 ORM 好费劲啊

我只说一点，国内 Mybatis 之所以全面取代了 Hibernate 的根本原因，就是因为 ORM 一旦要处理复杂查询，就会倒退回 sql 查询，因为 ORM 自己压根就无法处理复杂查询，没有哪个 ORM 工具能全面的处理复杂查询，而且现在根本不需要你自己拼接 sql 了，sql 语句事先写好，然后映射到方法上，参数化查询

@leeg810312
话别说太满：
1.现实是没有完全合理的系统
2.我不知道你有没有接触过复杂报表需求，千奇百怪的脑洞，没有复杂 sql 还真就搞不定，计算机建立的模型并不能完全模拟现实的，有的时候只能靠人工去补，你以为 ORM 就能对付所有情况吗。我建议你去了解一下为啥国内 Mybatis 基本全面取代了 Hibernate

@reus 有些人看的太少，他们忘记了一件事情，人类的计算机技术还远远没牛逼到了对现实直接建模的程度，这就注定了有一些业务只能迂回实现。这就造就了复杂情况

orm 复杂的也有坑

Java Jooq sql 封的解方案挺好的

当然是选择自己写啊。ORM 最适合单表。复杂点的，搞定 ORM 的时间够写 N 个 SQL 了。当然，也可以查视图。但是视图本身也是 SQL 写的啊。

低并发场景，例如订单，用户属性，用 ORM，高并发场景，如优惠券，活动用 SQL，但凡需要复杂的多表联合查询的，都用业务逻辑解决，数据库就是存数据的，不处理业务逻辑

@neoblackcap 我以为 Postgres 更流行呢...

@zhy0216 然而 postscript 也是图令完全的

@abcbuzhiming 国内 Mybatis 之所以全面取代了 Hibernate ? 各大软件厂商大量用，并且看看 mybatis 那更新速度能忍？ hibernate 周周发新版本 每次大版本更新很多功能都很惊艳。 我们现在做医院系统 几千张各种复杂的报表 没手写过一句 sql，用 pa 配合 java 8 没遇到不能满足的需求

@letitbesqzr “算钱的地方，就别用 Hibernate ”，这是当年 javaeye 长贴讨论后得到的结果，Hibernate 再更新来更新去，说白了还是把表映射为对象的那套思路，这套思路是有极限的，关系数据库并不完全是对象数据库。既然你没碰到必须手写 SQL 的场合，那就不要自以为是的觉得自己的系统已经足够复杂，那只是你所呆的环境比较幸运罢了。
我并没有说 Hibernate 就完全不适用了，另外其实我本人是反对为了写 SQL 去用 Mybaitis 的。

必然 ORM 啊 因为要么你就全 ORM 或者 99%以上 ORM 你一复杂就原生 简单就 ORM 不觉得代码看起来很奇怪吗？

@abcbuzhiming 为啥 用 sql 不一样 各种 sum count 统计？ hibernate 不一样可以？ 又是谁告诉你 现在的 hibernate。 那这样说吧 我在做银行的时候 也是大量用 hibernate 也不会写 sql，那请问银行的系统报表也是极简单？

@8355 感觉这个是为了 ORM 而去 ORM，实际项目中还是要灵活点么

@letitbesqzr 不觉得写起来还不如写 SQL 来的快

复杂的业务 SQL 还是去写存储过程吧

orm 只适合类单表操作，报表的还是得用 sql 直接

@assad 用 ORM 也不是为了仅仅替代 SQL 啊。
ORM 背后还要管理缓存，事务，动态查询构造。
在需要灵活性的场景下，全程拼接 SQL 难受。

@msg7086 单表和稍微少一点的 ORM 挺好使。但是复杂的报表，各种连，各种函数等，ORM 感觉没 SQL 来的爽，我们之前一个报表，DB 只给把老长的 SQL 写好了，直接用了事！

@letitbesqzr 真不想争辩了，银行的系统报表就一定是复杂的了？你连联表都没提，难怪还觉得 hibernate 能打天下呢。hibernate 这玩意要真有你想的那么万能，ibatis 就不会出现，就这话，多的不想说了，反正爱用啥是你的自由。不会再回复你

坚持写 sql，orm 感觉反而是复杂化了。写 sql 我脑袋更清爽些，我是做企业里各种稀奇古怪报表之类东西的，不用 sql 的话，没法完成。

@abcbuzhiming 报表是有专门的报表模块的，报表工具很重要，和普通的业务代码是分离的

简单的增删改查 ORM 是很完美的选择；略复杂一点的就用原生 sql ；报表：请用专业的报表工具；