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

[assad]

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

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

[abcbuzhiming]

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

[abcbuzhiming]

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

[aksoft]

orm 复杂的也有坑

[gap]

Java Jooq 這種 sql 封裝的解決方案挺好的

[ivvei]

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

[danielmiao]

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

[zhy0216]

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

[ryd994]

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

[letitbesqzr]

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

[abcbuzhiming]

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

[8355]

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

[letitbesqzr]

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

[assad]

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

[assad]

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

[xeneizes]

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

[Gathaly]

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

[msg7086]

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

[assad]

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

[abcbuzhiming]

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

[atcdef]

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