你们平时手撸 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