前面我们聊了前端和后端。
前端负责用户能看到、能操作的部分；后端负责处理数据、业务逻辑和安全。但只要你的项目不是一个纯展示页面，最终一定会遇到一个问题：数据放在哪里？
用户注册的信息放在哪里？订单数据放在哪里？文章内容放在哪里？聊天记录放在哪里？商品、任务、评论、文件、配置，这些东西都不可能只写死在代码里。
这时候就需要数据库。
这一小节，我们就来聊数据库。
这里同样不是教你马上写 SQL，也不是让你立刻成为数据库工程师，而是帮你先建立基本认知。因为在 Vibe Coding 里，如果你完全不懂数据库，AI 很容易帮你做出一个前期能跑、后期很难维护的数据结构。
一、什么是数据库？
简单来说，数据库就是专门用来存数据的地方。
前端负责展示数据，后端负责处理数据，而数据库负责长期保存数据。
一个用户注册之后，他的账号、手机号、密码哈希、创建时间，要保存到数据库里；一个订单创建之后，订单号、用户、商品、金额、状态、支付时间，也要保存到数据库里；一篇文章发布之后，标题、内容、作者、发布时间、审核状态，同样要保存到数据库里。
如果没有数据库，这些数据就只能临时存在内存里，程序一重启就没了；或者被写死在代码里，根本无法真正运营。
所以，数据库是项目的数据底座。一个项目能不能长期运行，能不能查数据、改数据、追踪历史、支撑后期功能扩展，很大程度上都和数据库设计有关。
二、为什么 Vibe Coding 必须理解数据库？
很多小白用 AI 做项目时，最容易忽略数据库。
前端页面能看，后端接口能调，就以为项目完成了。但实际上，很多时候数据只是假的，或者只是临时存在本地，根本没有真正进入数据库。
这类项目看起来能跑，但不能真正用。你刷新页面，数据没了；你换个账号，数据乱了；你部署上线，发现本地数据带不上去；你想加一个新功能，发现原来的数据结构根本支撑不了；你想统计用户行为，发现之前根本没有记录。
这就是数据库认知不足带来的问题。
在 Vibe Coding 里，这个问题尤其常见。因为 AI 很容易为了让功能先跑起来，临时造一个简单的数据结构。前期看起来没问题，后期功能一复杂，就会发现字段混乱、关系不清、重复数据一堆、权限也不好控制。
所以你不一定要会亲手写复杂 SQL，但你必须知道：数据不是随便存的。数据怎么存，决定了项目后面怎么查、怎么改、怎么扩展、怎么维护。
三、建议顺序：先 UI，再数据库，再后端
如果是完全靠 Vibe Coding 做项目，我更建议的顺序是：先写 UI，再设计数据库，最后写后端。
注意，这不是传统开发里唯一正确的顺序，而是更适合小白和 AI 协作的一种方式。原因很简单：UI 最容易把一个模糊想法变具体。
你一开始可能只知道自己要做一个管理系统、一个工具、一个小程序、一个交易后台，但具体需要哪些页面、哪些表单、哪些字段、哪些状态、哪些按钮，其实并不清楚。
这时候如果你直接让 AI 设计数据库，它很容易根据自己的理解随便猜。猜对还好，猜错了，后面前端和后端都会跟着错。
但如果你先把 UI 做出来，情况就不一样了。页面里有什么列表，列表就暗示了你需要哪些数据字段；页面里有什么详情页，详情页就暗示了数据对象的完整结构；页面里有什么表单，表单就暗示了用户会提交什么数据；页面里有什么按钮，按钮就暗示了需要哪些操作；页面里有什么状态，状态就暗示了数据流转过程。
也就是说，UI 会倒逼你和 AI 把数据形式想清楚。
等 UI 和流程基本确定之后，再让 AI 根据页面反推数据库结构，就会靠谱很多。因为这时候它不是凭空设计数据库，而是根据已经看得见的页面、字段、状态和操作来设计。
你可以让 AI 根据前端页面回答这些问题：这个列表需要什么表？这个详情页需要哪些字段？这个表单提交后要保存到哪里？这个状态从哪里来？这个按钮操作会改哪条数据？
数据库确定之后，再写后端也更顺。后端要做的事情，本质上就是围绕数据库和业务流程提供接口。数据库里有哪些表，前端需要哪些数据，用户会做哪些操作，这些都清楚了，后端接口才不容易乱。
所以这个顺序可以理解成：先用 UI 明确产品形态，再用数据库固定数据结构，最后用后端把页面和数据连接起来。
这样做的好处是，AI 更容易理解项目，小白也更容易验收结果。因为你先看到页面，再看到数据结构，最后再看接口逻辑，整个项目是从看得见的东西一步步落到看不见的系统里。
四、数据库服务、数据库、表和字段是什么关系？
对小白来说，理解数据库最重要的第一步，就是搞清楚数据库服务、数据库、数据表和字段之间的关系。
很多人会把它们都叫数据库，但严格一点说，它们不是一回事。
数据库服务，可以理解成正在运行的数据库软件。比如你在服务器上安装并启动了 MySQL 或 PostgreSQL，这个运行起来的东西就是数据库服务。
一个数据库服务里，通常可以创建多个数据库。比如一个数据库服务里，可以有项目 A 的数据库、项目 B 的数据库，也可以有测试数据库和正式数据库。
数据库，则可以理解成某个项目的数据空间。一般来说，一个项目会对应一个或多个数据库。对于小白做项目，通常先理解成一个项目对应一个数据库就够了。
数据库里面会有很多数据表。数据表负责存放某一类数据，比如用户表专门存用户，订单表专门存订单，商品表专门存商品，文章表专门存文章。
字段，就是这张表里每条数据需要记录哪些信息。用户表里可能有用户名、手机号、密码、头像、注册时间这些字段；订单表里可能有订单号、用户 ID、商品 ID、订单金额、订单状态、创建时间这些字段。
一张表里的一条完整数据，通常叫一条记录。比如用户表里的一条记录，就是一个用户；订单表里的一条记录，就是一笔订单；商品表里的一条记录，就是一个商品。
所以它们的关系可以简单理解成：数据库服务里可以有多个数据库，数据库里有很多数据表，数据表里有很多字段，字段定义了一条记录里要保存哪些信息，记录则是真正保存进去的一条条数据。
你也可以把它想象成一个办公楼。数据库服务像整栋办公楼，数据库像办公楼里的一个公司，数据表像公司里的不同部门，字段像每个部门固定要登记的信息项，记录就是一条条真实登记进去的信息。
你在 Vibe Coding 的时候，一定要让 AI 把这个关系说清楚。不要只让它说“我创建了数据库”，你要让它告诉你：当前用的是什么数据库服务？创建了哪个数据库？这个数据库里有哪些表？每张表存什么？每张表有哪些字段？字段分别代表什么？表和表之间怎么关联？
因为数据库设计不是随便建几个表就完事。如果数据库服务、数据库、表、字段这些层级没分清，小白很容易搞不懂自己到底是在连接数据库服务，还是在操作某个具体数据库，也搞不懂 AI 到底把表建到了哪里。
五、常见数据库类型和怎么让 AI 选型
数据库有很多种。
如果按是否开源来分，可以简单分成开源数据库和不开源数据库。
开源数据库里，最常见的有 MySQL、PostgreSQL、SQLite、MongoDB、Redis、ClickHouse 等。MySQL 和 PostgreSQL 都是非常常见的关系型数据库，适合大多数业务系统。SQLite 更轻量，适合本地应用、小工具、原型项目或者嵌入式场景。MongoDB 是比较常见的文档型数据库，结构更灵活。Redis 通常用于缓存、临时状态、排行榜、验证码、会话等场景。ClickHouse 常见于数据分析和日志分析类场景。
不开源数据库里，比较常见的有 Oracle Database、Microsoft SQL Server、IBM Db2 等。这些数据库通常出现在企业级系统、传统行业、金融、电信、政企项目里。它们往往有成熟的商业支持、权限体系、审计能力和企业服务，但使用成本、部署成本和学习成本也会更高。
除了按是否开源来分，也可以按数据模型来分。
关系型数据库，比如 MySQL、PostgreSQL、SQLite、Oracle、SQL Server，通常用表来组织数据，很适合用户、订单、商品、文章、权限这类结构清晰的数据。
非关系型数据库，比如 MongoDB，更像是用文档来存数据，结构相对灵活，适合一些变化比较快、结构不那么固定的场景。
缓存数据库，比如 Redis，通常不是用来长期保存核心业务数据，而是用来加速访问、保存临时状态。
向量数据库，在 AI 项目里会更常见，通常用来存文本、图片、音频等内容的向量表示，方便做相似度搜索、知识库检索、RAG 等功能。
对普通 Vibe Coding 项目来说，大多数业务项目常见建议是优先考虑 MySQL 或 PostgreSQL。它们成熟、稳定、资料多、生态完善，足够覆盖大多数后台系统、SaaS、内容系统、电商系统和工具类项目。
当然，这不代表你要自己拍脑袋选，也不是让 AI 随便选一个就开干。更合理的方式是让 AI 根据业务类型给出推荐，但必须要求它说明理由。
你可以问 AI：这个项目更适合 MySQL 还是 PostgreSQL？为什么？如果选 MySQL，后期可能有什么限制？如果选 PostgreSQL，会不会增加部署和维护成本？这个项目有没有必要用 MongoDB、Redis 或向量数据库？如果没有，为什么不需要？
你还可以让 AI 最后给出一个明确结论：当前项目推荐使用哪个数据库，原因是什么，不选其他数据库的理由是什么，后期如果项目变复杂，是否需要引入新的数据库组件。
这样不是让 AI 替你随便决定，而是让 AI 把选择过程讲清楚。你不一定完全懂数据库，但你至少能看到它有没有认真分析业务场景，而不是拍脑袋选型。
六、数据库设计常见概念
理解了数据库服务、数据库、数据表和字段的关系之后，再看其他概念就容易多了。
主键，是一条数据的唯一标识，通常用来区分每一条记录。比如每个用户都有一个用户 ID，每笔订单都有一个订单 ID。
唯一键，是用来保证某个字段不能重复的约束。比如手机号、邮箱、用户名、订单号这些字段，很多时候都不应该重复，就可以设置唯一键。
自增，是让数据库自动生成连续编号的一种方式。比如用户 ID 可以从 1 开始自动往后加，不需要你每次手动指定。
外键，可以理解成两类数据之间的关联。比如一笔订单属于某个用户，订单表里就需要记录它对应的是哪个用户。
索引，是为了让数据库查询更快的一种结构。数据少的时候你可能感觉不到，数据多了以后，没有索引的查询会变慢。但索引也不是越多越好，索引太多会影响写入速度，也会让数据库结构更复杂。
查询，就是从数据库里找数据。
写入，就是把新数据保存到数据库。
更新，就是修改已有数据。
删除，就是移除数据。删除通常要非常谨慎，尤其是真实业务数据。
迁移，是数据库结构发生变化时的变更记录。比如新增字段、新增表、修改字段类型，都应该通过迁移来管理，而不是随便手动改。
这些词后面你会经常遇到。你不需要马上精通，但至少要知道它们分别在说什么。
七、数据库最容易翻车的地方
数据库最容易翻车的地方，通常不是一开始跑不起来，而是后面越做越乱。
第一种，是表结构设计太随意。该分开的数据没有分开，所有东西都塞进一张表，前期看起来省事，后面查询、统计、权限和扩展都会变麻烦。
第二种，是所有数据都塞进一个大字段。看起来省事，实际上后面很难筛选、统计、排序和维护。
第三种，是表之间关系没设计清楚。用户、订单、商品、权限这些数据之间怎么关联，如果一开始没想清楚，后面接口和业务逻辑都会变乱。
第四种，是没有数据校验。用户提交的数据不一定可信。金额、手机号、邮箱、状态、数量，都需要校验，否则脏数据会进入数据库。
第五种，是没有迁移记录。项目迭代时，数据库结构一定会变化。如果没有迁移记录，后面开发环境、测试环境、线上环境很容易不一致。
第六种，是删除太随意。很多真实业务里，数据不能说删就删。删除之前要考虑是否有历史记录、是否影响统计、是否需要恢复。
第七种，是敏感信息处理不当。密码不能明文存储，密钥不能放进前端，用户隐私数据不能随便暴露，数据库连接信息也不能泄露。
第八种，是唯一性和索引没设计好。该唯一的字段没有唯一键，后面就可能出现重复手机号、重复邮箱、重复订单号。该加索引的字段没有索引，数据一多查询就会变慢。但索引加得太随意，也会拖慢写入、增加维护成本。
这些问题如果前期不管，后期会非常麻烦。
八、最后
这一小节，你先记住一句话：数据库是项目的数据底座。
前端让用户看到数据，后端处理数据，数据库保存数据。对 Vibe Coding 来说，你不一定要会亲手写 SQL，但你必须知道数据库在项目里负责什么。否则你很容易以为项目完成了，实际上只是前端假数据；你以为数据保存了，实际上没有真正入库；你以为功能能用了，实际上数据结构根本支撑不了后期扩展。
如果你完全靠 Vibe Coding 做项目，我更建议的顺序是：先写 UI，再建数据库，最后写后端。因为 UI 能帮你和 AI 看清楚页面、流程和数据形式；数据库能把这些数据形式固定下来；后端再根据数据库和页面流程去实现接口、权限和业务逻辑。这样项目会更稳，AI 也更不容易乱猜。
尤其是当项目要上线、要接用户、要长期运营时，数据库一定不能随便糊弄。
你要学会问 AI：当前用的是什么数据库服务？创建了哪个数据库？数据库里有哪些表？每张表有哪些字段？字段分别代表什么？表和表之间怎么关联？这个业务类型为什么适合这个数据库？为什么不选其他数据库？哪些字段需要唯一键？哪些 ID 适合自增？哪些字段需要索引？哪些操作需要事务？哪些数据不能直接删除？敏感信息怎么保存？
这些问题，决定了你的项目是一个能跑的 demo，还是一个真的可以继续迭代的产品。
