SQLAlchemy 架构 — 初学者学习后端的笔记

Source: Dev.to

请提供您希望翻译的正文内容，我将为您翻译成简体中文，并保留原有的格式、Markdown 语法以及代码块和 URL。

什么是 SQLAlchemy（简明版）

SQLAlchemy 是一个用于操作关系型数据库的 Python 库。

起初，我以为 ORM 意味着“没有 SQL”。SQLAlchemy 证明了这个想法是错误的。

使用 SQLAlchemy：

• SQL 仍然重要
• 表和关系仍然重要
• Python 对象是可选的，而非强制的

它并不隐藏数据库，而是小心地将其暴露出来。

“数据库抽象”的真实问题

许多工具试图让数据库变得不可见：

• 没有 SQL
• 没有模式（schema）思考
• 看不到连接（joins）或约束

这种感觉很舒适，却违背了现实。

关系型数据库之所以强大，是因为它们严格：

• 模式的存在是有原因的
• 关系是显式的
• SQL 有规则

对象追求灵活性，数据库要求准确性。这种冲突始终存在。

SQLAlchemy 并不试图逃避这种冲突。

SQLAlchemy的核心哲学

SQLAlchemy 并不试图保护开发者免受数据库的影响。

它的理念：

• 必须理解关系
• 必须看到 SQL
• 自动化应当减少重复，而不是减少思考

这就是为什么 SQLAlchemy 称自己为 toolkit，而不是框架。

它允许抽象泄漏：

• 你可以看到正在发生的事情
• 你可以控制行为
• 没有任何强制或隐藏

Core vs ORM（这花了点时间才明白）

SQLAlchemy 被划分为两层。

Core

Core 是基础层。它负责：

• 数据库驱动通信
• SQL 构造
• 表和列的定义
• 连接与执行

重要要点：

• Core 可以单独使用，不依赖 ORM
• Core 与 SQL 紧密贴合
• Core 始终可用

这消除了我对 “SQLAlchemy 等同于 ORM” 的误解。

ORM

ORM 构建在 Core 之上。它增加了：

• 将 Python 类映射到表
• 身份追踪
• 更改追踪与持久化

核心理念：

• ORM 是可选的
• ORM 永远不会阻断对 Core 的访问
• 你可以随时回退到底层

这种分离让人感觉更为诚实。

设计成本

因为一切都是分层的：

• 发生了许多函数调用
• Python 函数调用很慢

SQLAlchemy 通过以下方式减少这些：

• 优化热点路径
• 内联逻辑
• 在需要时使用 C 扩展

设计保持简洁，而不是被重写为低层代码。

为什么仅仅使用 DBAPI 不够

DBAPI 只是一套宽松的规范。不同的驱动行为各不相同：

• Unicode 处理方式不同
• Binary 处理方式不同
• 参数风格不同
• 获取最后插入的 ID 方式不同

这种不一致是危险的。SQLAlchemy 的存在就是为了统一这些差异。

引擎、连接、结果（思维模型）

SQLAlchemy 将原始数据库访问封装成清晰的层次。

• Engine – 入口点。了解使用哪个数据库和驱动程序。
• Connection – 代表一个实际的数据库连接。
• Result – 整洁地封装返回的行和元数据。

直接使用 DBAPI 的情况消失了。

方言（关键概念）

方言定义了：

• SQL 在特定数据库中的写法
• 驱动程序特定的行为
• 类型转换
• 参数格式化

每个方言针对：

• 一个数据库
• 一个驱动程序

这解释了 SQLAlchemy 如何干净利落地支持多种数据库。

ExecutionContext

每次查询运行时：

• 创建一个短暂的执行对象
• 在那里处理运行时细节
• 将 SQL、参数和结果关联起来

方言定义规则；ExecutionContext 在运行时应用这些规则。

处理支持多种数据库的驱动程序

一些驱动程序可以与多种数据库通信。SQLAlchemy 通过以下方式处理：

• 共享通用行为
• 仅在需要时添加特定数据库的逻辑

没有重复。没有猜测。

最终理解

我学到的最重要的一点：

关系型数据库本质上是严格的。SQLAlchemy 并不假装相反。

相反，它：

• 使规则可见
• 自动化重复性工作
• 将控制权交给开发者
• 能够平滑地从原始 SQL 扩展到 ORM

这种设计感觉真实，而非魔法。