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

[assad]

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

我比较倾向于拼装原生
简单的可以使用 ORM

[springmarker]

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

[mokeyjay]

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

[coolair]

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

[TangMonk]

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

[Ouyangan]

orm 什么 sql 拼不了啊...

[shoaly]

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

[leeg810312]

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

[111111111111]

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

[zhy0216]

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

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

[zhy0216]

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

[fuxkcsdn]

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

[cloud107202]

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

[neoblackcap]

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

[visonme]

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

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

[BOYPT]

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

[reus]

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

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

[annielong]

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

[assad]

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

[assad]

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

[abcbuzhiming]

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