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

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

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

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

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

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

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

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

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

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

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

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

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

写模板 SQL 然后生成代码

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

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

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

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

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

用 ai 写啊

crud 用 ORM ，报表手写

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

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

我是基本上只用 ORM

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

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

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

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

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

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

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

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

没必要手写的就不会手写

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

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

.net 里我用的 efcore

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

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

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

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

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

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

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

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

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

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

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

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

但是程是先 sql ，在 dbeaver 面行定之後，然後把他化代面的 orm 。

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

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

@artiga033 正解

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SQL first

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

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

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

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

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

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

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