用了一段时间的 SQLAlchemy，感受到的只有混沌和混乱

[Richard14]

作为一个初学者，最近带着学习的目的用了一段时间，因为我本人水平比较菜，本文无意对 sqlalchemy 提出任何批评，只是描述一些我使用中遇到的问题。

我没有什么 orm 使用经验，因为我司涉及的业务往往是大连表复杂查询，感觉 orm 不能带来多大的节省脑力的优势。平常我们业务中使用数据库，脱离开增删改查之外，更多的脑细胞应该是耗费在数据库储存原理上，如何规划数据和优化性能本身，虽然这部分花费的时间应该是最少。我从未想到有一天自己能在增删改查上耗费这么多的精力。

SQLAlchemy 在我这个初学者看来有若干明显问题，其中主要的就是设计上的混乱。随着新版本更新后，sqlalchemy 的世界（按我的划分），应该有三种分类方法，他们分别是

1. ORM 和原生的区别。一个 orm 同时支持原生 sql 语言完全可以理解，支持原生混用也还可以接受，但是再复杂呢？
2. 同步和异步的差异。2022 年已经快到了，使用异步代码访问数据库完全不是什么行为艺术，而是非常正当和迫切的需求。
3. 1.0 和 2.0 风格的差别。据我观察它写的不是那么好的文档，sqlalchemy 有过一次语法设计上的大升级。

这三者组合之下就形成了 8 种搭配。从同步的->原生的->1.0 风格的代码，到异步的->ORM 的->2.0 式的调用，不一而足。在学习过程中文档本身就没有避免这种混乱，而有任何问题搜寻网络资料的话就更不一而足了。由于这是一个跨时间很长的项目，历史资料往往不能起到帮助，有时甚至会起到误导作用。而且作为 2022 年的项目，自然要尽可能地保证设计风格统一，就算网上找来一段代码可以 work ，如果它来自于不同的设计思路，融合进项目真的是好主意吗？

根据我的观察，ORM 还是很有必要的东西，包括虚拟的连接层，实际上起到的是数据库本身的内存优化的作用。在需要频繁读写业务数据的时候除了降低程序员心智开销，另一方面也能实打实地提高负载能力。但是我真的想吐槽这两天在网上找到的混乱的资料，还有让人一眼读不懂的文档，以及迁移到异步只给了一篇寥寥的说明，让我完全无法 get 到它的设计精神，以至于很多问题不能通过直觉解决，而网上的资料又全部过期。。

另外还有就是我作为初学者对于 ORM 的数据同步真的很疑惑，按照它的设计我无法理解数据同步是在哪里发生的，什么时候显式地发生，什么时候又隐式地发生，我在多端同时操作时什么时候需要注意脏读脏写问题。。。

总之我无意批评 sqlalchemy ，我知道所有的问题都是因为我太菜了，人家肯定有解决方案。但是用的这几天感觉是真的头大。。

[thedrwu]

哈哈哈，我有类似的体验，但是知道说出来就会被人喷

[alexkkaa]

这个库硬是把 py 写成了 java

[sagaxu]

orm 引入了复杂度，降低了性能，单表 CRUD 或者两三个表联表的简单查询还能用用

[coreki]

只能简单 crud ，复杂一点还是要用原生 sql

[WangBold]

没错，越用越蚌埠住。

[0Zed]

同感

[ospider]

> 根据我的观察，ORM 还是很有必要的东西，包括虚拟的连接层，实际上起到的是数据库本身的内存优化的作用。
仔细看文档吧, 之所以分成 core 和 orm 两个层次就是为了让你可以只用链接池这种基础组件, 而不用全部都用.

> 很多问题不能通过直觉解决，而网上的资料又全部过期。。
SQLAlchemy 能查到的资料确实有很多过期的, 但是还是比较好分辨和转换的吧, 基本看到带 query 的代码就是老风格的, 其他的就是 1.4/2.0 风格的.

> 我司涉及的业务往往是大连表复杂查询，感觉 orm 不能带来多大的节省脑力的优势。
CRUD 比较适用 ORM, LDAP 你用啥 ORM...裸写 SQL 才是正途, 不过像上面说的, 依然可以用到 core 部分.

> 使用异步代码访问数据库完全不是什么行为艺术，而是非常正当和迫切的需求。
同步和异步比较混乱是 Python 的锅, SQLAlchemy 不背

[raptor]

我们只用 core 的部分，还是很爽的。简单 crud 部分少量使用 orm 也很灵活方便。但如果想全部用 ORM 那的确会比较困难……然而哪个 ORM 不困难呢？

[sadfQED2]

😂😂我也同感，最后不用了，但是我不敢说，怕被人喷人菜怪框架

[makelove]

因为不喜欢这类 ORM 风格和增加没必要复杂性（相对于简单的 sql ）,所以我直接写了自己的 ORM （ 1500 行左右代码）。

其实我的核心要求就很简单：
1 和自定义 class 绑定以便在数据行上写逻辑，这也是各类 ORM 的最大好处
2 查询字段强类型
3 基本 CRUD 以覆盖大部分日常 sql 操作
在 sql 上面搞出非常复杂的对象关系、查询都是无谓地增加复杂性

[RangerWolf]

我自己就推荐使用 sqlalchmey 来帮忙维护连接池，其他地方全是裸写 SQL

[Huelse]

我的 sqlalchmey 就是个池子管理员

[fgwmlhdkkkw]

我自己写了一个，不过还没有文档
https://github.com/zzztttkkk/orm

[ebingtel]

看了一下 api 文档，感觉函数命名风格都不统一，就劝退了……peewee 真香

[flniu]

SQLAlchemy 是基于 data mapper pattern 的 ORM 。如果是复杂查询比较多的业务，不如试试基于 active record pattern 的 ORM ，比如 Peewee 。

[flniu]

用 Peewee 基本上思维方式跟原生 SQL 很像。而 ORM 又帮你解决了连接管理、防范 SQL 注入的问题。

[so1n]

我都是裸写 sql 的， 在 ide 的帮助下裸写 sql 很爽， 当然在一些后台管理的需求我还是会使用 orm

[adoal]

“大连表复杂查询”，会不会被分词引擎分出一股海蛎子味来……

[adoal]

从你自己写的就可以看出来，更多的问题是因为，1.项目演进的问题 2.SA 跟你的项目的匹配度问题

至于 SA 本身的设计路线，当然也是个问题，但并不是跟你带来痛苦的关键

[adoal]

建议：
1. 因为项目跨度太长，必然会产生屎山和各种风格不一致，还是调整心态吧。
2. 虽然“2022 年已经快到了，使用异步代码访问数据库完全不是什么行为艺术”，但项目不是 2022 年开始的，是周期长跨度到 2022 年的，不要给自己找麻烦去迁移异步了。如果是新项目可以。
3. 既然是海蛎子查询，那还是现实一点吧。