Golang Go语言中关于sqlx等的纯sql库的不解的一点

发布于 1周前 作者 wuwangju 来自 Go语言

在 go 节点一说到 orm 相关的，很多人都说 自己用 sqlx+sql builder 类似的库，或推荐类似库

但有个疑问就是 sqlx 这类的东西如何实现关联查询，比如一对一、一对多的模型关系，并且是易于使用的关联查询

然后就是项目复杂后，数据库的访问也变的复杂。这类简易库真的能在生产环境里高效开发吗，更容易开发吗？最终是不是还会自己整出个简易的 orm 库，那为何不一开始就用 orm 的库呢？


Golang Go语言中关于sqlx等的纯sql库的不解的一点
Harmonyos Next教程
9 回复

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

更多关于Golang Go语言中关于sqlx等的纯sql库的不解的一点的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


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

有时候直接用 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 也根本就不支持，这些功能就是手写的。

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/

关于Golang中sqlx等纯SQL库的一些疑惑，我作为GO语言方面的专家，可以为你进行解答。

sqlx是Go语言内置database/sql的超集，它在database/sql的基础上提供了一组扩展，让数据库操作变得更加高效和灵活。以下是对sqlx的简要介绍：

  1. 安装与连接：通过go get命令安装sqlx后，可以使用sqlx.Open函数连接到数据库。连接方式与database/sql非常相似，但sqlx在建立连接时提供了更好的错误处理和日志支持。
  2. 查询操作：sqlx提供了StructScan方法，可以直接将数据库中的记录扫描到Go结构体中，避免了手动扫描每一列数据并赋值给结构体的繁琐过程。
  3. CRUD操作：sqlx提供了简洁的API来执行插入、更新和删除操作，可以直接使用db.Exec方法，并获取执行结果，如受影响的行数或插入的自增ID。
  4. 命名参数：sqlx支持命名参数，可以使用NamedExec和NamedQuery方法进行参数绑定，使代码更清晰，参数绑定更直观，减少了SQL注入的风险。

总的来说，sqlx是一个功能强大且灵活的Go语言数据库操作库。如果你对sqlx还有其他疑惑或需要更深入的了解，建议查阅官方文档或相关教程。

回到顶部