大家喜欢用 ORM 还是直接写 SQL

我一直喜欢写规范的 SQL ，奈何前些年 ORM 更流行。

比较喜欢 orm ，

投 SQL92 一票。
小项目怎么顺手怎么来。
大项目特别是有性能要求的，ORM hold 不 hold 得住先？

首先，MyBatis 配置开启驼峰命名映射时，也不用写 resultMap ，在 MBP 中也是默认开启的。

个人的话简单项目用 JPA ，复杂项目用 MBP 。不讨厌 XML ，更喜欢原生的 SQL 。

我个人更喜欢 ORM ，但我是写 C# 的。

有些比较复杂的 sql 要写简直要死，我 sql 写不好，有些需求完全没有思虑，现在用 gpt 写

都用，简单的 orm ，复杂的 sql

喜欢手写 sql ，但是代码里如果有变量还是 orm 。python 有啥好用的 orm

据我观察，大部分 Java 和 Go 开发者对 ORM 无感甚至讨厌 ORM ；而大部分 C#、Node.js 、Ruby 开发者喜欢用 ORM 。
原因其实很简单，C# 的 EF Core 、Node.js 的 Prisma, MikroOrm 、Ruby 的 ActiveRecord 很好用。

一款好的 ORM 应该尽可能提供该语言原生的写法，提供完善的类型安全、提供灵活的 Query Builder 以应对尽量多的 SQL 语法。

Java/Go 生态内缺少用起来顺手的 ORM 。要是 Java 有 EF Core 、Go 有 Prisma ，我相信所有人都会喜欢 ORM 。

C#, ORM

@just1 我用 python 的 peewee,感觉还可以

orm 好用的多，特别是那种关联关系
手写 sql ，如果在后续需求中，需要加入软删除，是不是每个 sql 都要检查，包括链表查询
还有一对多和多对多，后续调整的时候，如果手写这种 sql ，是不是差不多项目要重构了？如果用 orm 的话，就简单很多了
有说如果 sql 很复杂，orm 的性能跟不上，可能我代码写的少了，我并没有遇到 sql 很复杂的情况，如果 sql 很复杂多链表的情况，一般都是 分成多个简单的 sql ，然后用程序处理的吧

这是我设计的内置 sql 的语法：
return db.queryAll(User -> u where ids.contains(u.id) orderby u.createBy desc select u.id, u.name)

不确定我理解的对不对。ORM 主要解决的是编程语言数据类型与数据库类型不一致，进而实现了，切换数据库而不用修改代码的结果。

但是这种结果在现实条件里太少了，没有人会无聊了换数据库玩。

那么回到语言类型与数据库类型不一致的问题上来，其实自己解决也并没有多麻烦，特别是现在许多数据库支持一些非简单类型的数据，（例如 JSON/Blob 等等），对于这些类型，ORM 反而支持的不太好，还不如自己手写。

所以现阶段来看，我粗浅的认为，ORM 并不是必须的（也就是说并没有解决什么实质上的问题），依据个人习惯来好了。手搓 SQL 更能控制 SQL 语句的质量与规模。我想没几个项目从头至尾都是简单的单表查询吧，多表查询，ORM 生成的语句质量，一般也就是个中规中矩，能用的水平。

c#, 看场景吧.
一般情况下 EF Core 搞定.
二般情况比如用 timescaledb 的时候就 dbup + 手写迁移文件.

肯定 ORM ， 我还是无法理解动态 SQL 怎么用原生好写？难不成自己封装一个类优雅的组装， 结果只有自己会用，到头来就是不肯用开源的呗？

我写 c#，我用 freeSql 的，ef 我觉得太重了，freeSql 主要是比较灵活，想 orm 就 orm ，想 sql 就 sql ，里面直接一个 ado 拿出来，想咋用就咋用，配置也很简单，各种 aop 功能方便调试

@gam2046 现在数据库之间的差异 太大了.已经不是 orm 能弥补得了.

对于日常两三张表 join 以上的情况 只有手写 sql.
如果日常不 join 表 那肯定可以用 orm.

肯定是都用啊

PHP 的 ORM 天下第一

JAVA 里如果有 EF Core 就不会有 ORM 好不好用这个问题出现了

我只知道原生 SQL 防 SQL 注入很麻烦，特别是自己拼的原生 SQL 。而如果你自己做防注入了，又很像在干 ORM 该干的事情。

ORM 的话，因为我写 python ，公司的项目用的 SQLAlchemy+FastAPI+Gino ，稍微有点学习成本，有些写法文档也没介绍，会有隐藏的坑，但是熟悉之后写起来还是挺舒服的。

性能肯定是原生好，因为 ORM 除了负责把代码对象变成 SQL 语句去执行，还要把查询结果又加载成代码对象，写起来是很舒服，但是中间的转换是有代价的。

python+sqlalchemy ，非常好用，三四张表 join 起来没什么问题

rubiest ，必然是 ORM 啊。

工作 5 年了 只用 orm
没有 orm 完成不了的 sql

前端，喜欢 orm ，但是写 go 发现没有一个 orm 是好用的。。。

复杂的用 SQL, 简单的逻辑判断用 ORM 更方便

简单 CURD 用 ORM ，复杂查询写 SQL （比如连表或者用了 OR ）

歪个楼，Java 21 的字符模板真的好丑陋

@Features 确切说, 是 Eloquent 天下第一

@woodfizky alchemy2.0 自身也有对异步的支持，为啥要用 gino 呢？我没接触过 gino

@eliot121450375 可以说是遗留问题了。。当时还用的是 SQLAlchemy1.3 ，那时候还不支持异步。
不过 Gino 可以兼容 SQLAlchemy 的语法，加上连接池用的也是 Gino 的，就这么用下来了。

--portfolio
WITH all_transfers AS (
SELECT "from", "to", token_address, -value AS value_diff
FROM erc20_transfers_from_shard
WHERE "from" = LOWER(0x9B1bbecdf6409ff6F7cAE9DA2C4d2C7f6b8CF9E9')
UNION ALL
SELECT "from", "to", token_address, value AS value_diff
FROM erc20_transfers_to_shard
WHERE "to" = LOWER('0x9B1bbecdf6409ff6F7cAE9DA2C4d2C7f6b8CF9E9')
),
sum_transfer AS (
SELECT token_address, SUM(value_diff) AS sum_value
FROM all_transfers
GROUP BY token_address
),
price_usd_token AS (
SELECT sum_transfer.token_address, sum_transfer.sum_value, tokens.price_usd, tokens.decimals, tokens.symbol,
(tokens.price_usd * sum_transfer.sum_value) / POWER(10, tokens.decimals) AS total_value
FROM sum_transfer
INNER JOIN tokens ON tokens.address = sum_transfer.token_address
WHERE tokens.decimals != 0 AND tokens.decimals IS NOT NULL AND tokens.is_hOneypot= false
)
SELECT token_address, symbol, sum_value, total_value, price_usd
FROM price_usd_token
WHERE total_value IS NOT NULL AND total_value > 0
ORDER BY total_value DESC;


复杂的还是 SQL 舒服

SQL ，ORM 把简单的问题搞复杂了

混着用，现在的 ORM 框架还配有代码生成器，传个表名进去一波帮你生成到前端 crud 界面了，还是很省心的。但是复杂业务用 ORM 就有点多余了。

ORM 对一些业务处理很方便 sql 也很重要

那些说喜欢 ORM 的来，多表链接 + 多个子查询 + 聚合查询 + 动态条件，用 ORM 给我写个看看

肯定 Orm 啊，后期维护都简单很多，纯 Sql 语句后期维护太麻烦了。

@just1

python 不是只有 3 个嘛，django,sqlalchemy,Peewee

原来用 C# 的时候，用过 Stack Overflow 开源的 dapper ， 用 C#的 强烈推荐 这个库。

现在基本是手写 sql .
事务控制 、 复杂 SQL 等场景， 还是手写舒服。 防注入的话，不要拼接客户端的内容，查询用参数就 OK 了。

@monkeyWie 大点的业务一般都不让连表和聚合。ORM 的优势正是动态条件，几十个条件拼接，完全不用考虑语法错误，SQL 拼接会死人的。

php 的 orm 用着比 java 的爽多了

自己做的小项目喜欢直接 sql 。 其他 orm

自己写喜欢写 SQL ，但是代码里看到同事的 SQL 就会想死....那还是大家一起用 ORM 吧。

laravel 的 orm 会对一些联表之类的查询进行优化，比如批量的一对多的子查询，laravel 会先把所有 id 查出来，然后再根据 id 把所有的子数据查出来再聚合，基本上就是 n + 1 条请求就解决了；
但是 mybatis 即使映射了 association 和 id ，也是会循环查 id ，再循环查子数据

当时从 php 转 java 的时候发现，phper 如此牛逼和人性化，java 如此落后。奈何国内潮流是 Java

直到我发现了 nodejs ，哈哈~

@gam2046 Confluence 后端就是大量 ORM ，涉及各种表关联都必须精心维护好 Entity ，这类产品有一个特色是卖给不同的客户群体，可支持不同的 DB

让你看看真正的 SQL


直接手搓 sql ，别人也能看得懂，
复杂的逻辑可以取完值后再做逻辑运算。

最近在做信创迁移，A 系统中存在大段手写的 MySQL 方言，B 系统基本上使用的都是 mybatis 框架实现的（ SQL 标准兼容比较好）。两个系统的迁移成本估计为 5:1 ，因此从可维护性角度还是建议采用 ORM 框架

go 的 ent 谁用过，介绍介绍经验

@sunmoon1983 这啥啊

@sunmoon1983 以前接手过这种项目, 当时就想把写这种 SQL 的人拉出去砍了

@hongye 那明显是 A 好啊。要是都得 A 至少有多四个人有活干，养活一家老小。你可能只是用一个简简单单的 orm 框架，未来有四个人因为你的这一举动而失业，换不起房贷，老婆和别人跑了，3 个还不是自己的，收手吧

@XCFOX 我用 gorm ，感觉挺好用的，生成的 SQL 基本上和手写 SQL 差不多。还有很多灵活的表达式写法。

@flmn 用过，还行，感觉比 gorm 好用，就是生成的 SQL 很垃圾，强制加 distinct ，不知道最新版改了没有

与其说 sql 好用不如说是 java/go 系的 orm 不够好用。。。
尝试写过 go 的 orm 。。。那时候泛型还没出，建个模型自己写都写的头大，背起来更是蛋疼，那可不是 sql 好用嘛。。。

可能弱类型对这块有先天优势？
至少 nodejs 和 php 的 orm 确实很好用，非要写一堆 join 和专有语法也可以自己 mod ，至于性能影响。。。拼个 sql 能有性能影响你就不该上弱类型。。。

目前我感觉没有 ORM 的体验能和 Rails 的 ActiveRecord 相媲美

不存在真正的 ORM 框架，因为这里面的 M 通常是对应数据库表的 entity ，这种模型压根做不了业务
另外我用 kotlin 和 KTORM 还是挺爽的
XML 里写 sql 是最丑的

@lifei6671 我也喜欢用 GORM ，不可否认的是 GORM 确实很不优雅、很不 ORM ，但是感觉……他做到了便携性与灵活性的一个 balance……很怪，我个人也觉得 GORM 丑不垃圾的，但感觉真的很好用

@CloveAndCurrant 改了

@yule111222 羡慕 Kotlin ，只能私下玩玩 Kotlin ；我就是因为 XML 才很不想用 MyBatis……太丑陋了，但在 dynamic where conditions 上 MyBatis 又挺好用的……（与 JdbcTemplate 相比）

@musi ent

MyBatis-Plus 的函数式查询条件, 非常好用, 字段名没有硬编码

肯定 ORM 啊，我们这程序也不止支持一种数据库

go 下用着 Ent, 写起来很 fluent

java 开发，混用，单表 ORM ；联表 SQL

@sunmoon1983 #47 逻辑能力太强了

@monkeyWie 大脑一根筋吗？用了 ORM 就不能手写 sql 了？什么场景用什么方法。

@jadeborner #68 有没有可能是有人只用 ORM 不手写 sql 呢，反正不是我

写过 PHP 、Go 、Python：
PHP 的大框架 orm 最好用，用起来很丝滑。
GO 用过 xorm 和 gorm ，现在简单的用 gorm ，复杂的写原生 sql 。
Python 现在 SQLAlchemy ，复杂的基本都能 hold 住。

@sunmoon1983 这条 sql 是不是直接保住了饭碗，没人敢动

公司的项目需要适配至少 7 个数据库，尽管各家数据库都支持标准 sql 语句，但业务逻辑没有那么简单，所以还是会使用 orm

能用 ORM 的地方 别用 SQL 就行了

ORM 更多的还是为了表达业务逻辑, 毕竟编辑器里面搜变量的 赋值/读取 还是很方便的

拼出来的 SQL 我觉得是没法维护的

手写 SQL ，水平不行，还可能被注入～ 能 ORM 就 ORM

ORM 实现不了、性能过低才考虑 SQL

前端人员用 nestjs 写后端，用 typeorm ，复杂 sql 用 sql

看业务，orm 优先。

@monkeyWie 关键是动态查询 orm 比较好做吧.像管理后台,一个用户列表或者订单列表,框框就是高达 10 个动态查询,sql
完全想不出来应该怎么弄. 至于 sql,我也只会简单 sql 啊.orm 最主要的问题可能就是两张表,都有字段要查的话,我不知道怎么做,因为我表设计的时候,基本只查一张表.很多时候甚至会把两张表合成一张表.虽然最佳实践肯定不是这样的,但是
做起来简单啊.最关键是并发不大

我们查询的报表 sql 一堆函数和嵌套，orm 不太适合这种场合

不要在意项目大小，小项目最终也会演化出大量的关联查询。对 SQL 本身的封装要好过 ORM 。

还真可以，其他 ORM 不熟不知道，python + SQLAlchemy 完全可以做到 join + sub_query + union_query + group_by + 动态传入 and 、or 条件，写熟悉了跟写原生 SQL 的思路是差不多的

我工作写 java 的，日常用 mybatis plus ，像 JPA 那种 ORM 还是用不来，黑箱太多了，有种不安全感。还是根据场景来吧，简单的单表会用 mybatis plus 的 CRUD 接口，涉及联表还是手写 SQL 比较舒服，清晰明了，别人理解起来也容易。把联表拆成多个单表查询，然后用 mybatis plus 其实也可以，出现问题也方便调试，但是代码量太大了，写起来一大坨，别人也不好理解

表设计好，orm 当然效率更高。表设计差，当然 sql 更好写。

以前写 C#用 SqlSugar ，真的神中神，目前没见过能超越这个的 ORM
Linq 写 SQL ，爽的不行

这个问题和具体的语言关系还是蛮大的， 像 python 的 peewee ，orm 写起了思维方式和原生的 sql 基本一致，用的时候很少遇到需要手写 sql 的情况，但是写 GO 的时候就没这么顺滑了，还要把脑子里的 sql 转义成 orm 的语法才能写下来

用过 Ruby 的 ActiveRecord 后，你就会发现，在座的各位都是。。。

Rails +1 ，Java 和 Go ，属于语言限制了 ORM 的发挥，元编程能力越强，ORM 越强。

Go 之前有个新项目用过 Gorm ，但是体验不是很好，遇到过几个小坑，官方的文档也很久没更新过了。
后面就只用 sql builder: Squirrel 或者直接写 SQL 了

以前喜存程和 SQL

在喜 ORM

静态语言的强大 ORM ，虽然它自称 Functional Relational Mapping (FRM)

https://scala-slick.org/doc/3.0.0/introduction.html

什么方便用什么；
什么用的熟练用什么；
原生 sql 写起是非常爽，奈何处理业务逻辑有时候反而更麻烦。这时候就该 orm 上场了。

建议写 Java 的都来看看 PHP 的 ORM ，哈哈哈 https://laravel.com/docs/10.x/queries

C#，EF Core 确实 NB ，但我现在倾向于使用轻量极 ORM 了：因为我在推独立服务。而且之前有次 EF Core 升级搞出很多问题，我觉得服务需要确定性所以在尽量减少 EF Core 的使用了。

Eloquent ORM：在座的各位都是辣鸡

用 jooq 写 type safe 的 sql

https://www.jooq.org/doc/latest/manual/sql-building/sql-statements/select-statement/set-operations/set-operation-typesafety/

https://blog.jooq.org/to-dao-or-not-to-dao/

一开始 只写 sql
后来 混用
现在 只用 orm
业务简单 已经很多个项目 不写 sql 了 太舒服了

不考虑性能只追求方便 orm, 复杂查询和性能追求原生 sql

drizzle 的 orm 我觉得很好

ORM 封装太重，裸写 SQL 太麻烦坑也太多，最喜欢的是 knex.js 这种 SQL builder ，以及 objection.js