你们平时手撸 SQL 多吗？还是 ORM 优先

[tangmanger]

最近接手一个项目，里面有好多 SQL 语句，然后拿到 ORM 执行 SQL 字符串 话说，有 ORM 平时有什么场景需要手写 SQL 的

[CoderGeek]

很少手写了 除非有那种框架搞不了的 手写还容易犯错

[Dorathea]

"好多 SQL 语句，然后拿到 ORM 执行 SQL 字符串 "
这啥意思, ORM 不就是为了不手动写 SQL 么 = =

[tangmanger]

@Dorathea 比如 写个 sql= select * from AA _db.excute(sql)

[gam2046]

经常写，稍微复杂一点的多表查询，ORM 生成出来的只能说是能运行，但效率都不太好。

除非是一些单表查询，生成出来的，一般都问题不大。

[Dorathea]

说回正题吧, 我是[不用 ORM]( https://blog.codinghorror.com/object-relational-mapping-is-the-vietnam-of-computer-science/) 那一派的, 我觉得小项目不需要, 大项目谨慎使用

[yvyvyv]

crud 员一般都是 ORM ，写的快可读性好，交接起来也容易。
连表查询有索引都是慢查询的时候，就用 sql 替代 ORM(因为我 ORM 理解的不够透，还是写 sql 优化容易一些)

[cccvno1]

需要查一些老项目的表的时候，不是所有表设计的都是那么规范的，这时候直接写 sql 查完了再用 orm 将结果映射成对象更方便。
我觉得 orm 的核心还是映射，能将返回结果映射成结构体就够了。
可以看看 C#的 dapper ，写一些小项目或者运维小工具挺爽的。

[lbunderway]

数据统计往往要 sql 才好写，orm 不容易实现，我们项目就是 sql 用的多

[WDATM33]

看业务，比如写个报表 所有数据放业务层处理太复杂了， 还是直接 sql 一次性查出数据好处理点。

[pangdundun996]

复杂点的项目一般都是手写 sql 吧

[irisdev]

表结构复杂、数据量大还是写 sql ，人家几十年研发的引擎肯定比查完自己拼强

[lynnworld]

写模板 SQL 然后生成代码

[canteon]

一直都是手写 sql ，框架或者自己写一个语法糖，能预编译就行。orm 也用，偷懒的时候用 orm 。其实最主要的是因为 orm 还要去看文档，虽然每个框架思想大差不差，也能看懂。如果你要是维护那种老的项目，或者压根是一个不了解的框架，你就知道原生 sql 的方便处了。我现在就在看用 ruby 写的一个老项目，sql 天天有慢查询。全是用 orm 写的，找位置都挺费劲的

[zjsxwc]

看情况，2 着都用，都灵活使用，今天还在群里看到有人用这个 sql ，就是比用 ORM 方便

[bronyakaka]

复杂的 sql 都是自己写，orm 不仅丑，效率也不好

[i8086]

单表 CRUD 都用，报表手写 SQL ，性能方向也是手写 SQL 。

[lujiaxing]

简单的东西直接 EFCore 出来就是了. 但是复杂的 (例如报表), 必须手写 SQL. 没办法.

[bf109_]

用 ai 写啊

[Hieast]

crud 用 ORM ，报表手写

[betteron]

自己的项目 || 不强制要求 orm = 直接手搓 sql
其他的情况,orm,但是复杂的 sql 还得是 orm,即使项目大也是如此

[v1]

发版上线初期先用 orm 写，然后打点测，下一版的时候全部改成 sql （ orm 直接生成），然后手动处理性能问题的 sql 和优化慢查询

[Smileh]

我是基本上只用 ORM

[Smileh]

@Smileh #22
前面说什么 orm 效率不好的，orm 不也是转 sql 吗
有啥效率不好，只能说用的不熟

[KingHL]

orm 也有 SQL 优先类型的，想要简洁高效可以尝试换这种 orm 。

[zsc8917zsc]

曾经写了上万行存储过程练就了肌肉记忆....即便很多年不写了，再上手也是唯手熟尔。
但是现在已经不写 sql 了，能用框架用框架，用不了框架～ All in AI

[loading]

基本手写，有时要对接其他数据库，直接手写方便快捷，你告诉我 ORM 怎么整，先不算定义吗？

[soap0X]

单表查询 orm 复杂的还得 sql 不然不好优化

[Shamiko]

用 query builder ，简单查询用封装好的 api ，从来不手写 sql

[w3cll]

简单的 ORM ，复杂的就手搓，要不然不好优化

[linecode]

都是 orm ，我看手写的还不如 orm 生成的 sql 好

[way2create]

没必要手写的就不会手写

[bingfengfeifei]

golang 用 GORM+Gorm Gen ，之前用 sqlx 手撸的，有个大版本迁移到 GORM gen 上面了。效率提升了很多。
只需要写建表 SQL ，然后自动生成结构体，CRUD 代码。
幸亏迁移到这套框架上，最近有个需求是国产化信创数据库兼容，本来用的 MySQL ，现在要兼容人大金仓(PG)，如果不用这套 ORM 的方式，估计要改死我。

[artiga033]

看语言生态。
要是写 C#我都不知道怎么会有人能忍得住不用 EF Core+LINQ to SQL 的。
Golang 的 ORM 基本都是残废，属于简单查询用 ORM ，复杂查询手写 SQL 的状态。
现在用 rust 比较多，因为没有好用的 orm ，所以选择干脆不用 SQL 数据库，用 MongoDB 。

[DomenicCarter]

.net 里我用的 efcore

nodejs 里我用的是 drizzle orm （这个站就是 nextjs + drizzle orm 写的： http://gamocean.com/ )

写 SQL 维护起来麻烦，尤其是换数据库时。

[changz]

没见过几个能把手写 sql 结合代码写得好的，手抖下还容易搞出各种安全问题

[esee]

@changz 注意 sql 注入， 禁止多行 sql 执行，就能避免 99%的问题了吧。或者你说的安全问题是指什么？

[Ketteiron]

2025 年了，手写也不是真的纯一大串文本，有 sql build 框架能用，它们会负责底层的安全问题，真要论安全，手写比 orm 安全性更方便，因为更直观更容易检查出毛病。orm 在单表查询大于多表查询的项目里比较好，sql build 在多表以及复杂查询场景更好，也不能简单的分个强弱，如果某个框架能够做到完美地结合二者就好了。

[v1]

@dssxzuxc 2025 年了，要培养一线产品对接、业务支撑、销售们手写 sql 了，反正有 ai 嘛 /滑稽

[yb2313]

我最喜欢的就是手写一千行 sql 然后直接当做业务逻辑关键节点, 然后创建多个视图多层依赖, 并且不写任何文档, 桀桀桀

[cnbatch]

有如果有合规检查的话，那就一律用 ORM ，并且是合规认可的 ORM ，一旦出现 SQL 漏洞之类的，可以甩锅

不需要合规检查，那就怎么简单怎么来，短语句手写，“长篇大论”式语句可以交给 ORM

[surbomfla]

直接使用 AI 判断，AI 觉得简单 ORM 能处理就使用 ORM ，不能的话 使用 SQL 语句，目前 几乎没有什么 SQL 语句 AI 处理不了的吧。

[shigella]

写 Dotnet 的时候用 ORM 比较多，写 Java 的时候就五五开更多时候愿意自己写 SQL ，自由度大

[LitterGopher]

在代码上的体现肯定是 orm 優先，除非使用的 orm 沒有相關語句的語義化方法，不然都是使用 orm 。

但是編碼過程還是先寫 sql ，在 dbeaver 裏面執行確定沒問題之後，然後把他轉化爲代碼裏面的 orm 。

[kakki]

除了 OLAP 很少很少直接写 SQL 低于 5%.

[MIUIOS]

从不手写 sql ，都是查出来拼接，比 sql 好维护

[liuliuliuliu]

@artiga033 正解

[rlds]

用 orm 也就只是减少了一些基础查询的手写 sql ，要是一些复杂的业务统计还得自己手写 sql

[SoviaPhilo]

用 native sql 的前提是这个项目不会因为外部原因， 比如合规化要求，需要做数据库迁移。

迁一次就知道， 众多的语法糖和数据库方言有多恶心了

[Narcissu5]

手写，因为 ORM 只能支持 SQL 很小一部分特性，比如 INERT INTO ... SELECT ,效率真的爆炸

[7gugu]

手写+AI ，把表结构提供给 AI ，用自然语言描述一下就好了，质量好效率高

[bronyakaka]

@Smileh #23 只能说你不懂 sql 优化

[cheng6563]

R 多手写，除非只是简单的 byId 条件就直接 ORM 。
CUD 多 ORM ，除非要大批量处理。

[Smileh]

@bronyakaka #51
公司的 sql 80%都是我优化的，
BI 大部分都是我写的
数据统计需求基本上全我写的
是你使用的 ORM 不熟练还是不支持
导致你一直写原生 SQL ，

[Ethan212]

站巨人肩膀上，orm 就是用来摒弃屎山 sql 的。

[zhhqiang]

orm 比较多，sql 感觉参数拼进去 可能会有其他问题。

[MaoRong]

看成你们平时手撸吗，，，

[0x663]

如果碰到需要兼容多种数据库（信创需求量大，各家信创数据库语法格式不一）的情况，ORM 会好切一些，sql 的话要写多份兼容。
实时工作流开发的话用 sql 比较多写，数据入湖的 sql

[vipfts]

@CoderGeek 戒撸了, 现在都让 ani 帮我

[worldgg]

用 ORM ,因为不确定客户想要用什么数据库。方便兼容不同数据库。

[frank42a]

SQL first

[hoosin]

看情况，比如 ClickHouse 这种分析型数据库，SQL 写起来更直观

[changz]

@esee 你这话说的。。。我注意不写 bug ，就不会有 bug 了？

[meshell]

即使是用 orm ，也可以用 create builder 来写代码式的 SQL 吧

[bbbblue]

都是 sql builder
java 用 jooq
nodejs 用 drizzle
ORM 用不惯...sql builder 还是写 sql 的路子 多了一点编译期安全

[mshadow]

我对好用的 ORM 定义:
1.完善的模型映射
2.提供好用的基础 CRUD 功能
3.提供好用的 sql builder

基于此，
业务中占比超高的单表简单 CRUD ，直接使用 ORM 提供的，
剩下的绝大多数能用 sql builder 搞定，
极少数特殊的，自己写 sql 或者 sql builder 生成后自己二次处理一下。

[WithoutSugarMiao]

自工作以来，就没手撸过。