- 支持试读
为什么选择 sqlx 而不是 ORM？
本章我们先讨论一个问题：为什么选择 sqlx 而不是 ORM？ - 支持试读
基本CRUD
本章我们将讨论使用 sqlx 和 PostgreSQL 执行基本的 CRUD （增删改查）操作。 Executor
本章我们探讨 sqlx 使用最频繁的 trait：Executor。同时还将讨论如何通过参数传递事务。- 支持试读
使用 sqlx 操作 PostgreSQL 数组
PostgreSQL 原生支持数组。本章将讨论如何使用 sqlx 操作 PostgreSQL 的数组。 把 PostgreSQL 变成 MongoDB
MongoDB 等 NoSQL 异军突起的原因之一就是解决了传统关系型数据库的一大痛点：数据的扩展性，与此同时，NoSQL 又丧失了关系型数据库的范式。PostgreSQL 原生支持 JSON，通过这一特性，可以将 PostgreSQL 打造为同时兼备关系型数据库和 NoSQL 数据库的六边形数据库。把 PostgreSQL 变成 Redis
PostgreSQL 支持 hstore 数据类型：一种简单的键/值对。配合无日志表，我们可以将 PostgreSQL 打造为简单的缓存服务。把 PostgreSQL 变成消息队列
PostgreSQL 原生支持异步通知。本章我们将探讨通过 PostgreSQL 的异步通知，打造一个消息推送服务。
为什么选择 sqlx 而不是 ORM？
- 8623
- 2025-01-18 15:47:27
强类型语言中，数据库操作的痛点是什么？
在 Rust 等强类型语言中，操作数据库最大的痛点当然是 Rust 语言的数据结构（比如：结构体、枚举等）与数据表字段的映射。
这也是很多人用 ORM 的主要原因之一吧。
另一个痛点是，书写 SQL 语句。尤其是在数据表比较复杂或者更改数据表定义时，这个问题尤其突出。
真的需要 ORM 吗？
那么，真的需要 ORM 吗？不可否认，ORM 提供了高度抽象，让数据库操作变得犹如操作结构体等原生数据结构。但它的弊端也很突出：
-
过度抽象：为了实现如操作结构体般操作数据库，ORM 进行了高度的抽象，甚至到了过度抽象的程度。虽然 Rust 语言的宏（在 Rust 中，ORM 基本都是通过宏来实现功能）提供了零成本抽象，但过度抽象给程序的调试，以及程序员对流程的把握带来了不少的挑战，更不用说优化 SQL 语句了。
-
生成的 SQL 过于通用：
- ORM 通常为多种数据库提供支持，这就意味着，它生成的 SQL 语句是通用的，很大机会用不到数据库引擎提供的优化功能
- ORM 为了实现各场景通用，也只能生成通用的 SQL 语句
-
某些 ORM 提供 RAW 的概念，允许用户书写原始 SQL 语句。为了弥补生成 SQL 过于通用或者适用某些需要优化 SQL 语句的场景，某些 ORM 允许用户书写原始 SQL 语句。我都手写 SQL 语句了，为什么还要用 ORM？
sqlx 能解决哪些痛点？
- 首先，sqlx 能实现 Rust 数据结构与数据表字段的自动映射
- 其次，使用 sqlx 必须手写 SQL 语句，不会自作聪明地给你生成通用的、低效的 SQL 语句
等下，你刚刚说，手写 SQL 语句尤其是在复杂表或修改表结构时，是一大痛点，你现在又在推 sqlx 不是自相矛盾？
借助 AI 编程助手，SQL 语句基本就告别手写了。
免费 AI 编程助手
免费 AI 编程助手既有传统的根据上下文代码智能补全，也有比较新奇的通过 chat 直接生成整个项目的工具。
本人用的是 Codeium 做代码补全，偶尔会用 Cline 来做一些测试用的小项目，同时会使用 Cherry Studio 来做一些转换，比如将 SQL CREATE 语句转换成对应的 Rust 数据结构。