什么是数据库？面向应用构建者的指南
数据库是应用用来保存和读取信息的一个有组织的存储，比如用户、订单、预约和消息。与只保存在浏览器标签页中的信息不同，数据库中的数据在刷新或重启之后依然存在，而且使用该应用的每个人看到的都是同一批记录。大多数数据库把数据组织成表，很像电子表格中的工作表，但它们有严格的规则来保证数据的一致性。
用 AI 做应用时，为什么这很重要
使用 AI 构建应用的人最常遇到的意外，是应用看起来已经完成了，却忘记了所有东西。你添加了一位客户，刷新页面，结果客户不见了。这通常说明应用是把数据保存在浏览器的内存里，而不是数据库中。
数据库也是许多最重要的决定所在的地方，不论你是否意识到：
- 你记录什么。 如果你不保存预约的状态，就无法显示哪些预约已被取消。
- 事物如何关联。 一位客户能否拥有多个预约，或者一个预约能否包含多项服务，决定了整个应用的结构。
- 谁能看到什么。 大多数隐私问题都与用户能读取哪些记录有关。
你不需要亲自设计数据库。但理解基础知识，能让你清楚地描述自己的数据，并及早发现问题。
日常类比
想象一间井井有条的小型办公室里的文件柜。
每个抽屉存放一类东西：一个抽屉放客户，一个放预约，一个放发票。每个抽屉里，每个文件夹都遵循相同的格式，填写相同的字段。每个文件夹都有唯一的编号，当一张发票属于某位客户时，发票文件夹会记下那位客户的编号，而不是把整份客户档案复印一份。
这就是关系型数据库。抽屉是表，文件夹是行，字段是列，编号是主键，而指向另一个文件夹的备注就是外键。一位好的办公室经理还会执行规则：没有日期的预约不能录入，两位客户不能有相同的编号。数据库也是这样执行规则的。
实际例子：一个美发店预约应用
假设你请 AI 为一家美发店构建预约网站。一个合理的数据库会有四张表。
services（服务）
| id | name | duration_minutes | price |
|---|---|---|---|
| 1 | 剪发 | 45 | 40.00 |
| 2 | 染发 | 90 | 95.00 |
staff（员工）
| id | name | |
|---|---|---|
| 1 | Sara | sara@example.com |
| 2 | Omar | omar@example.com |
customers（客户）
| id | name | phone | |
|---|---|---|---|
| 101 | Lena Park | lena@example.com | 555-0100 |
bookings（预约）
| id | customer_id | service_id | staff_id | starts_at | status |
|---|---|---|---|---|---|
| 5001 | 101 | 1 | 2 | 2026-10-03 14:00 | confirmed |
看看 bookings 这张表。它没有把 Lena 的姓名和电话复制到每一条预约里，而是只存储 customer_id = 101。如果 Lena 更换了电话号码，只需在一个地方修改，每条预约都会显示新号码。这正是关系型数据库的核心思想：每个事实只存一次，然后通过链接去引用它。
同样的结构也能回答一些有用的问题：
- “Omar 周五哪些时段空闲？”——查看 Omar 当天的预约。
- “本月染发服务的收入是多少？”——将预约与服务表关联，再把价格加起来。
- “哪些客户 90 天没有预约了？”——将客户与他们最近一次预约进行比对。
常用术语说明
| 术语 | 含义 |
|---|---|
| 表（Table） | 同一类记录的集合，比如客户或预约。 |
| 行（Row / record） | 表中的一项，比如一位客户、一条预约。 |
| 列（Column / field） | 每一行都有的一项信息，比如邮箱或价格。 |
| 主键（Primary key） | 每一行的唯一 ID，通常是一个数字或随机字符串。 |
| 外键（Foreign key） | 指向另一张表中某一行的列，比如预约表中的 customer_id。 |
| 模式（Schema） | 整体设计：有哪些表、每张表的列以及它们如何关联。 |
| 查询（Query） | 读取或修改数据的请求，比如“明天所有的预约”。 |
| SQL | 结构化查询语言（Structured Query Language），关系型数据库的标准查询语言。 |
| 迁移（Migration） | 对模式的一次已保存、可重复执行的修改，比如新增一列。 |
| 索引（Index） | 一种查找结构，让对某列的搜索更快，就像书的索引。 |
| CRUD | 创建（Create）、读取（Read）、更新（Update）、删除（Delete），是应用处理数据的四项基本操作。 |
| 备份（Backup） | 数据的一份副本，出问题时可以用来恢复。 |
数据库的类型
| 类型 | 存储方式 | 示例 | 适用场景 |
|---|---|---|---|
| 关系型（SQL） | 具有固定列以及表之间关联的表 | Postgres、MySQL、SQLite | 大多数业务应用：预约、商店、CRM、SaaS |
| 文档型（NoSQL） | 灵活的类 JSON 文档 | MongoDB、Firestore | 每条记录的结构差异很大的数据 |
| 键值型 | 通过键存储值 | Redis | 缓存、会话等短期数据 |
对于创业者或小企业首先要构建的几乎所有应用，关系型数据库都是安全的默认选择。
数据库在应用中的位置
访客不会直接与数据库通信。他们浏览器中的页面（前端）通常通过 API 向你的服务器（后端）请求数据。服务器会检查请求者的身份及其权限，然后查询数据库，并只把该用户应该看到的内容发送回去。
这一中间环节很重要。如果浏览器可以带着完全权限直接查询数据库，任何人打开开发者工具，就能读取所有数据。
常见错误与误解
- 只把数据保存在浏览器里。 浏览器存储（比如 localStorage）只存在于一台设备、一个浏览器中。它适合用来记住一个筛选条件，但不适合保存订单。
- 把所有东西塞进一张表。 一张“预约”表里，每一行都复制了客户的姓名、电话和服务价格，很快就会不同步。
- 明文保存密码。 密码应当经过哈希处理，绝不能以可读形式存储。参见什么是身份验证。
- 数据没有规则。 如果没有必填字段和唯一性规则，你就会得到没有日期的预约和重复的客户。
- 忘记删除的问题。 要决定删除客户时，是同时删除他的预约、保留预约，还是直接阻止删除。
- 用生产数据做实验。 在安全的地方先测试有风险的修改，并保留备份。
- 永远把电子表格当作数据库。 电子表格很适合起步，但在多人同时使用和权限管理方面会力不从心。参见如何把电子表格变成应用。
向你的 AI 生成工具提出的要求
- “把这些保存到数据库里，而不是浏览器中。告诉我你会创建哪些表。”
- “用一张简单的表格展示模式：每张表、它的列以及它们如何关联。”
- “一位客户可以有多条预约；每条预约恰好对应一项服务和一位员工。”
- “客户的邮箱必须填写，并且唯一。”
- “阻止同一位员工的两条预约时间重叠。”
- “只有已登录的店主可以读取所有预约；客户只能看到自己的预约。在服务器端强制执行这一点。”
- “删除某项服务时，不要删除过去的预约，而是将该服务标记为停用。”
Mythex 中的数据库
当你的应用需要保存数据时，Mythex 会为项目添加一个专用的 Postgres 数据库。你可以在聊天中提出要求（“把候补名单的报名信息保存到数据库”），也可以使用 /database 命令。连接信息会自动传给你的应用，并由智能体创建表。数据库在空闲 5 分钟后会进入休眠，并在下一次请求时唤醒；已发布的应用则按数据库处于唤醒状态的时长计费，计费从与构建相同的积分余额中扣除。免费版和 Pro 版都可以使用。数据库文档涵盖了所有细节，而应用模板则提供了数据驱动的入门起点。
常见问题
简单来说，什么是数据库？
数据库是一个有组织的信息存储，应用可以向其中保存数据，也可以从中读取数据，比如用户、订单或预约。与只保存在浏览器标签页中的数据不同，数据库中的内容在刷新、重启之后依然存在，而且有人从其他设备打开应用时也能看到。
电子表格是数据库吗？
电子表格可以保存同类数据，但它并不是为应用设计的。真正的数据库会强制规定每一列存放什么内容，可靠地关联各个表，能处理多人同时写入的情况，并控制谁可以读取哪些数据。
SQL 数据库和 NoSQL 数据库有什么区别？
SQL（关系型）数据库，比如 Postgres 和 MySQL，将数据存储在带有定义好的列以及表之间关系的表中。NoSQL 数据库，比如 MongoDB，存储更灵活的文档。大多数业务应用（预约、CRM、商店）都很适合关系模型。
我的应用需要数据库吗？
如果它需要记住用户输入的任何内容（注册信息、订单、消息、设置），并在之后或者对其他人展示这些内容，那么需要。纯信息型网站，没有会保存数据的表单，通常不需要。