1

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

2

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

4

6

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

7

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

8

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

9

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

11

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

12

写模板 SQL 然后生成代码

13

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

14

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

15

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

16

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

17

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

18

用 ai 写啊

19

crud 用 ORM ，报表手写

20

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

21

1

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

22

我是基本上只用 ORM

23

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

24

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

25

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

26

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

27

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

28

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

29

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

30

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

32

1

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

33

2

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

35

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

36

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

37

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

38

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

39

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

40

41

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

42

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

43

44

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

45

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

47

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

48

49

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

50

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

52

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

53

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

54

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

55

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

56

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

57

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

59

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

60

SQL first

61

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

62

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

63

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

64

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

65