- 支持试读
为什么选择 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？
- 26
- 2025-01-18 15:47:27
强类型语言中，数据库操作的痛点是什么？
这也是很多人用 ORM 的主要原因之一吧。
另一个痛点是，书写 SQL 语句。尤其是在数据表比较复杂或者更改数据表定义时，这个问题尤其突出。
真的需要 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 编程助手及免费 AI API
免费 AI 编程助手
免费 AI 编程助手既有传统的根据上下文代码智能补全，也有比较新奇的通过 chat 直接生成整个项目的工具。
- Copilot：提供了一定的免费额度
- Codeium：免费 AI 编程助手
- Cody：免费 AI 编程助手，好像需要 VSCODE 安装 Python 插件
- Cline：通过 chat 直接生成项目，可以使用多种 AI 模型。其 fork 版的 Roo Cline 更为方便的功能。
- Cherry Studio：支持多种 AI 模型的桌面应用
免费 AI API
现在很多为爱发电的朋友提供免费的 API，这些 API 支持主流的 AI 模型，并且可以通过每日签到来获取积分/金额，以便使用他们的 API：