!07-data-persistence-database_index.png (../../public/images/Advanced/07-data-persistence-database_index.png)
第七章：数据持久化与数据库
本章目录
### 7.1 数据存储演进 (./01-数据存储演进.md)
从内存存储到数据库的演进路径,各种存储方式的对比和适用场景。
### 7.2 关系型数据库基础 (./02-关系型数据库基础.md)
数据库的核心概念:表、主键、外键、关系、约束、索引等。
### 7.3 后端方案选择 (./03-后端方案选择.md) 🟡
BaaS、Serverless、Traditional Backend 三种方案的对比和选择指南。
### 7.4 数据库设计的核心理念 (./04-数据库设计的核心理念.md) 🟡
从 PRD 到数据库设计的完整流程,如何识别实体、定义关系、优化结构。
### 7.5 Prisma 入门 (./05-Prisma入门.md)
Prisma ORM 的安装、Schema 定义、迁移管理、Client 初始化。
### 7.6 数据库迁移实战 (./06-数据库迁移实战.md)
迁移工作流、常见迁移场景、生产环境迁移、数据迁移策略。
### 7.7 CRUD 操作详解 (./07-CRUD操作详解.md)
Create、Read、Update、Delete 的完整用法,查询优化,事务操作。
### 7.8 Supabase 配置与使用 (./08-Supabase配置与使用.md) 🟡
Supabase 平台的快速上手,数据库操作、身份认证、实时订阅、文件存储。
### 7.9 数据库选择决策 (./09-数据库选择决策.md) 🟡
PostgreSQL、MySQL、MongoDB、SQLite 等主流数据库的对比和选择建议。
### 7.10 数据库备份策略 (./10-数据库备份策略.md)
备份类型、策略选择、自动化备份、灾难恢复演练。
### 7.11 数据库性能优化 (./11-数据库性能优化.md)
查询优化、索引优化、连接池配置、缓存策略、性能监控。
### 7.12 实战避坑案例 (./12-实战避坑案例.md)
10 个常见错误及解决方案,最佳实践总结。序言
界面搭建得有模有样了，但你发现一个尴尬的问题：每次刷新网页，刚才填写的表单、生成的对话全都不见了。
老师傅告诉你，这是因为浏览器里的数据默认只存储在临时的内存中。想要数据在关闭或刷新页面后依然存在，你需要数据持久化。
他严肃地提醒你：数据是所有业务的基石。前端代码丢了可以重写，UI 丑了可以换皮，但如果数据库里的用户数据丢了、乱了，你的产品就彻底完了。这就是为什么后端开发往往比前端更注重严谨性——因为你守护的是产品的灵魂。
JSON 文件存储
持久化不一定上来就要装复杂的软件。最简单的方式，其实就是把你之前在配置文件里学到的 JSON 格式利用起来，把数据存成 .json 文件。每一条聊天记录或用户信息，本质上就是一段文本。把它保存进硬盘的文件里，下次读取文件就能恢复。这种方式让你瞬间理解了“数据库”的本质——无非就是高效地读写硬盘上的文件。
关系型数据库
虽然 JSON 文件简单，但当你数据多了，想找"所有住在北京且年龄大于 20 岁的用户"时，就需要遍历整个文件，效率极低。于是你接触到了 Relational Databases（关系型数据库）。老师傅让你把它想象成一个超级 Excel，理解它只需要掌握几个关键点：
- Table (表)：就是一个 Excel Sheet（工作表），比如
Users表。 - Row (行)：表里的一行，代表一条具体的数据（比如用户张三）。
- Column (列)：表里的表头，定义了数据有哪些属性（姓名、年龄、邮箱）。
- Primary Key (主键)：每一行数据的唯一身份证号（通常是
id），绝对不能重复。 - Foreign Key (外键)：用来关联其他表的线索。比如在
Orders（订单）表中记录一个user_id，就能顺藤摸瓜找到这个订单属于哪个用户。
如何判断 AI 设计的表结构好坏？ 新手往往很难一眼看出 Schema 设计得合不合理。老师傅传授了你一招**“AI 交叉论证法”**（俗称“炼蛊”）：你让 AI 1号 帮你设计好表结构，然后把生成的代码发给 AI 2号 或 AI 3号 ，问它：“作为一个资深数据库架构师，根据我的PED和实际业务场景，这个设计是合理的设计吗，有什么潜在的性能隐患或逻辑漏洞？” 通常经过两轮这样的“左右互搏”，你就能得到一个非常健壮的数据库模型。
Prisma Schema
就像你用 JavaScript 指挥浏览器一样，指挥数据库也有专门的语言，叫 SQL。但在你不需要专门去学它，因为我们有用来操作数据库的 Prisma 组件。你需要理解它的蓝图文件——schema.prisma。
你可能会问，这个复杂的文件是谁写的？是你需要背诵语法然后一个字一个字敲出来的吗？当然不是。它是 AI 从你的 PRD 文档里"悟"出来的。当你在 PRD 里写下"一个用户可以发布多篇文章"时，AI 读懂了这层业务逻辑，于是它自动在 User 表里加上了 posts 字段，在 Post 表里加上了 authorId 字段。你的工作不是写代码，而是检查 AI 是否正确理解了你的意图。
老师傅说："你可能以为数据库设计是技术问题，其实是业务理解问题。AI 能懂外键、索引，但'用户和订单是什么关系'需要你理解业务。你的工作不是写 SQL，而是检查 AI 是否正确理解了你的业务。"
为了能看懂 AI 交的作业，老师傅指着一段代码，逐行教你理解：
model User {
id Int @id @default(autoincrement()) // 整数类型，作为主键，自动+1
email String @unique // 字符串类型，必须唯一
name String? // 字符串类型，但在类型后面加了问号，表示“可选项”（可以不填）
createdAt DateTime @default(now()) // 时间类型，默认填入当前时间
posts Post[] // 关联关系：一个用户可以有多篇文章
}model：这就代表一张表。- 类型：
Int（整数）、String（文本）、Boolean（真假）、DateTime（时间）。 ?（问号）：这是新手的救星。它代表 Optional（可选）。如果你不确定一个字段是不是必填的（比如用户的“个人简介”），加上问号，数据库就允许它为空，否则一旦没填程序就会报错。@unique：代表这个内容（如邮箱）全表唯一，不能重复注册。
CRUD 操作
虽然不用写 SQL，但你必须把 CRUD（Create 增、Read 查、Update 改、Delete 删）刻在脑子里。这是所有数据库操作的基石，也是你指挥 AI 操作数据的核心通用术语。
数据备份
"在讲任何技术之前，"老师傅严肃地说，"先讲数据备份意识。数据是产品的灵魂，备份是开发的底线。很多人忽视了这一点，直到某天数据库崩溃，才发现所有用户数据都丢失了，这是灾难性的后果。
自动化备份不是可选项，而是必修课。备份策略要包括：自动备份（每天）、多地备份（云+本地）、定期恢复演练（验证备份可用）。太多人做了备份但从来没测试过，等到需要恢复时才发现备份文件损坏。
灾难恢复演练的重要性不亚于备份本身。如果没演练过，你根本不知道备份是否真的可用。"
数据库选择
为了实战，你接触到了 SQLite，它是一个轻量级的文件数据库，不需要安装，非常适合开发测试。但为了未来的扩展性，老师傅建议你使用 PostgreSQL。
之前提到的 Supabase 这种 BaaS（Backend as a Service）。它确实能覆盖 95% 的后端需求：PostgreSQL 数据库、Auth 认证、Storage 存储、Realtime 实时通信、Edge Functions 函数。对于快速 MVP 验证，这是一个不错的选择。
但老师傅提醒你，本教程推荐使用标准的 PostgreSQL，而不是被任何 BaaS 捆绑。标准 PostgreSQL 让你更深入理解数据库的核心概念，迁移成本更低，未来可以根据需求选择任意托管平台或自建。Supabase、Neon、Railway 等都只是 PostgreSQL 的不同托管方式，你掌握的是数据库本身，而不是某个特定的服务平台。这种"不被捆绑"的思路，在 AI 时代尤为重要。
为什么是 PostgreSQL？除了它是世界上最强大的开源关系型数据库之一，它还有两个让 AI 开发者无法拒绝的特性：
- JSONB 支持：它虽然是关系型数据库，但能像 NoSQL 一样直接存 JSON 数据。这意味着你可以把 AI 生成的那些结构不确定的复杂数据直接丢进去，既有规则（SQL）又有灵活性（NoSQL）。
- pgvector（向量检索）：这是 AI 时代的杀手锏。它可以存储和查询"向量数据"，这是实现 AI 长期记忆（RAG）的核心技术。选了 PostgreSQL，就等于为你的 AI 应用铺平了未来的路。
实战避坑
在实操中，你需要注意到两个坑：
坑一：Connection URL（连接字符串） 你经常看到 Error: Invalid URL 的报错。老师傅告诉你，连接数据库就像寄信，格式必须严格遵守：postgresql://用户名:密码@主机地址:端口/数据库名。任何一个标点符号错了，或者密码里包含了特殊字符（需要转义），都会导致连接失败。
坑二：Schema 与代码不同步（最重要的命令） 你让 AI 在数据库里增加了一个 phone 字段，AI 修改了 schema.prisma 文件。但当你运行代码时，程序却炸了，提示“User 上不存在 phone 属性”。你开始怀疑人生，老师傅却淡定地让你运行一句命令：npx prisma generate。
原来，Prisma 为了保证 TypeScript 的类型安全，需要根据 Schema 生成一份“类型定义文件”。每当你修改了数据库结构（Schema），都必须重新运行 generate 命令，告诉代码：“嘿，数据库结构变了，请更新你的认知。”
老师傅特意叮嘱：这个命令非常重要，以至于在未来你部署上线时的构建命令里，也必须把它加进去，否则线上的代码会因为不认识新的数据库结构而报错。