关于 sqlx 等的纯 sql 库的不解的一点

关联查询自己写 left join 呗。orm 并非那么不可获缺。习惯哪个用哪个，都一样。高效不高效的，都是 crud ，谁能比谁差哪去，又不是搞量子计算机 ai 飞升的谷歌 fellow.

@acehowxx 我个人感觉不应该一上来推崇纯 sql 的方式挖坑，就像要啥 vue, 要啥 react, 直接纯 js 写不香吗。别人对数据的访问封装库的存在就是解决数据沟通上的痛点，存在即有道理。

@jam1024 有时候直接用 sql 写反而是更舒服的，只是用 sqlx 解决防注入等问题吧

复杂的数据库请求，手写 SQL 基本很难避免，各个语言的 ORM 对于简单的查询支持都没问题，比如单表查询，简单的多表查询，但是一旦复杂起来，ORM 生成的 SQL 通常只是能用，但执行效率很一般。

另外就是一些关于数据库相关的特殊语法，ORM 支持程度也很有限。以我常用的 postgresql 为例，如果需要跨数据库查询，甚至需要使用 join 语句进行 update ，ORM 都无法完成，需要使用许多代码，先进行查询，数据送到应用程序内，再通过游标逐条判断进行 update 。而这些对于现代的数据库，基本上都提供了原生的支持。还是以我常用的 postgresql 为例，上面的需求只需要这样的一句 SQL 即可完成。

with t as (
select t1.identifier as tid,t2.created_at
from table_devices t1 left join dblink('self','select identifier,created_at from table_devices')
as t2(identifier text,created_at timestamp)
on t1.identifier = t2.identifier
)
update table_devices
set created_at = t.created_at
from t
where identifier=t.tid and t.created_at is not null

就我个人而言，ORM 的主要用途是提供了数据库表到编程语言的类（ golang 中的 struct ）以及数据类型的对应关系。如果不是单表操作，我更倾向于手写 SQL 。

至于 ORM 支持不同数据库之间的水平迁移，本身就是个伪需求，实际生产中，几乎不会出现底层数据库的切换。如果真的发生，本身就需要细致的测试。简单的 select/join 这种操作，原本就是所有关系型数据库都支持，并不需要 ORM 。而带有数据库特色的语法，多数 ORM 也根本就不支持，这些功能就是手写的。

@gam2046 ORM 其实可以理解为对数据库访问的辅助类，不管你怎么样，最终还是离不开自己构建一个方便的访问操作框架，所以一开始用别人现场的不好？功能不够的可以再加

首先，要表面我的 2 个核心观点就是不推崇所谓的一上来就纯 sql 库给自己挖坑，然后第二个是不要过分妖魔化 ORM 。 所谓纯 sql 库比 ORM 更好本来就是伪命题，是自己给自己制造焦虑，制造痛点。软件工程的最后肯定都是为了更易用，更通用。正如为何要用 IDE ，直接记事本手撸不行吗，为何要用 GUI ，直接 command line 不行吗，底层对精细化的掌控的追求的确是好，但必有大的牺牲。这里把 ORM 想象为对数据库访问的辅助集合就能更容易理解，纯 sql 的调用，后期为了方便易用，最终肯定也会写个类似的辅助集合，活着活着，就活成了“别人的模样”。

有人说 ORM 里你看不到 sql 的逻辑，ORM 里能打开控制台输出具体执行了哪些 sql 的功能吧。有人说 ORM 的性能不行，稳定性不行，难道说开发 ORM 的程序员都是傻 X ，故意弄一个很卡，很慢，很不稳定的库出来？即使有部分逻辑性能上有问题，但一般 ORM 的库都提供了易于扩展的方式，然后你可以修改为你认为的高性能的方式即可。然后是 ORM 一般也支持直接 raw sql 的方法或函数，如果原生的查询满足不了，还能直接执行 raw sql 。

我刚问过大司马，他说 OP 现在还在第一层，哈哈哈

以前看过这篇文章，觉得讲的蛮有道理，
这个东西本来就是一个取舍。
就看公司层面注重什么。


为什么要旗帜鲜明地反对 orm 和 sql builder 。

https://xargin.com/you-should-avoid-orm-and-sql-builder/