Vibe Coding立项：数据库设计规范

概览部分

内容摘要

本文详细讲解了数据库设计的完整流程，从业务对象识别、表关系确认、数据库选型到字段规范设计，强调了在项目初期应避免直接让AI生成数据库表结构。文章指出，良好的数据库设计能有效降低后期维护成本，提升系统稳定性，并通过分步骤说明如何与AI协作完成高质量的数据库设计。

核心观点

• 数据库设计应从业务流程出发，而非直接生成表结构
• 表之间的关系是数据库设计的关键难点
• 选择合适的数据库类型对项目稳定性和扩展性至关重要
• 字段命名和数据规范直接影响后续开发效率
• 数据库设计文件应作为版本控制的核心内容

---

目录

1. 数据库设计的误区
2. 从业务流程中提取核心对象
3. 确认对象之间的关系
4. 选择合适的数据库服务
5. 设计表结构和字段规范
6. 常见字段的规范建议
7. 先保留设计文件再建表
8. 写入实施计划再执行

---

1. 数据库设计的误区

关键观点: 在涉及数据库的项目中，不要让AI一开始就生成表结构，而应先进行完整的数据库设计。

很多开发者在开始项目时就直接让AI生成数据库表，这种做法看似快速，但容易导致后续问题。数据库不仅是存储数据的工具，更是整个系统架构的基础。它决定了数据如何存储、接口如何查询、页面如何展示、后台如何统计等。如果数据库设计混乱，不仅影响前端和后端的开发，还会显著增加后期的维护成本和运营成本。

更严重的是，一个设计不合理的数据库在数据量增大后，查询速度会变得非常慢。虽然有人调侃"数据库慢了就加钱上好服务器"，但真正的解决方案应该是从一开始就把数据库设计清楚。

因此，在正式使用AI生成数据库表之前，必须完成一套完整的数据库设计方案。

---

2. 从业务流程中提取核心对象

2.1 从业务场景中识别核心对象

关键观点: 数据库设计的第一步是从业务流程中提取核心对象，而不是直接让AI生成表结构。

数据库的设计应该来源于实际的业务场景。例如：

• 电商平台常见的对象有用户、商品、订单、支付记录、收货地址。
• 内容平台常见的对象有用户、文章、评论、点赞、收藏。
• 后台系统常见的对象有用户、角色、权限、操作日志。
• 约会系统常见的对象有用户、服务项目、预约记录、时间段、门店。

这些核心对象通常会成为数据库中的主要表。如果你的前端已经比较成熟，可以基于页面反馈的数据来识别这些对象。例如：

• 注册登录需要用户信息；
• 订单列表需要订单信息；
• 商品详情需要商品信息；
• 评论区需要评论信息；
• 权限管理需要角色和权限信息。

如果没有前端，也可以从立项文档或功能说明中推断出这些对象。但此时需要与AI进行更深入的讨论，因为需求文档可能不够详细，AI很容易遗漏一些业务对象。

---

2.2 与AI协作识别业务对象

在这个阶段，不要急于让AI生成表结构，而是要让AI明确说出项目中的核心对象，以及每个对象对应的业务场景。

你可以这样引导AI：

• “我们的项目中有哪些核心业务对象？”
• “这些对象分别对应哪些业务场景？”
• “是否还有其他潜在的对象需要考虑？”

这一步的目标是确保AI理解你的业务逻辑，而不是凭空猜测。

---

3. 确认对象之间的关系

3.1 表间关系的重要性

关键观点: 数据库最容易出错的地方不是字段缺失，而是表之间的关系没有理清。

一旦核心对象被识别出来，下一步就是确定它们之间的关系。例如：

• 用户和订单：一个用户可以有多个订单，一个订单只属于一个用户 → 订单表中需要包含 user_id。
• 文章和评论：一篇文章可以有多条评论，一条评论属于一篇文章和一个用户 → 评论表中需要包含 article_id 和 user_id。
• 用户和角色：如果一个用户只能有一个角色，可以在用户表中放 role_id；如果一个用户可以有多个角色，则需要创建用户角色关联表。

你需要让AI解释清楚每张表代表什么对象，以及它们之间是什么关系（一对一、一对多、多对多），并说明关联字段放在哪张表里，为什么这样设计。

---

3.2 如何与AI确认关系

你可以这样引导AI：

• “请说明用户和订单之间的关系。”
• “用户和角色之间是一对一还是多对多？”
• “评论表中需要哪些关联字段？为什么？”

这一步的目的是确保AI理解的是你的业务逻辑，而不是自己随意设计一套表结构。

---

4. 选择合适的数据库服务

4.1 常见数据库类型对比

关键观点: 选择数据库类型时，应根据项目规模和需求决定，优先选择成熟、稳定的方案。

对于大多数项目，推荐使用以下数据库：

类型	适用场景	特点
PostgreSQL	后台系统、内容平台、订单系统	支持复杂查询、事务处理、JSONB类型
MySQL	电商、社交、内容平台	性能优秀、社区支持广泛
Redis	缓存、登录状态、验证码、限流	高性能、内存存储、适合缓存
SQLite	小型本地工具、桌面应用	轻量级、无需配置

需要注意的是，Redis通常不是主数据库，而是用于缓存、登录状态、验证码等场景，用来减轻主数据库的压力。除非你的项目确实有高并发或缓存需求，否则不建议将Redis作为主数据库。

---

4.2 如何与AI讨论数据库选择

你可以这样引导AI：

• “我们项目需要什么样的数据库？”
• “为什么选择PostgreSQL而不是MySQL？”
• “是否需要引入Redis？为什么？”
• “本地开发和线上部署有什么不同？”

这一步的目的是确保AI理解你的技术栈和业务需求，并给出合理的建议。

---

5. 设计表结构和字段规范

5.1 数据库设计的三大范式

关键观点: 使用三大范式来规范表结构，减少重复和冲突。

第一范式：字段要原子化，一个字段只存一个明确含义。例如：

• 手机号 → phone
• 地址 → address
• 备注 → note

不要把手机号、地址、备注拼成一个大字符串。

第二范式：字段要围绕当前表的主对象。例如：

• 用户表 → 存用户信息
• 订单表 → 存订单信息
• 商品表 → 存商品信息

订单表可以通过 user_id 关联用户表，但不要把用户头像、昵称等信息反复塞进订单表。有些信息如收货人姓名、手机号、地址需要保留快照，因为用户之后修改了地址，历史订单不能跟着变。这种重复是有业务原因的，必须让AI说明清楚。

第三范式：字段之间不要互相依赖。例如：

• 用户表已经有 city_id，就不需要再存 city_name，否则城市名称一改，两边可能不一致。

三大范式的目的是让数据更清晰，减少重复和冲突。复杂的业务为了查询性能可能会做反范式设计，但这种情况必须让AI先说明原因，不能随便重复存字段。

---

5.2 如何与AI讨论表结构设计

你可以这样引导AI：

• “请说明用户表的字段设计。”
• “订单表中有哪些字段？为什么这样设计？”
• “是否有违反三大范式的情况？请解释原因。”

这一步的目的是确保AI理解你的业务逻辑，并按照规范设计表结构。

---

6. 常见字段的规范建议

6.1 用户表常见字段

关键观点: 字段命名和数据类型应统一规范，提高代码可读性和可维护性。

用户表常见字段包括：

• id：主键，唯一标识一条数据
• username：用户名
• email：邮箱
• phone：手机号
• password_hash：密码哈希值
• created_at：创建时间
• updated_at：更新时间
• deleted_at：软删除时间（用于审计）

字段命名建议使用英文下划线格式，如 created_at、updated_at，这样在后续开发中更容易对接接口和代码。

---

6.2 注意事项

• 密码不要存明文，要存 password_hash。
• 金额不要用浮点数，可以用分为单位的整数，或者使用数据库中的精确数字类型。
• 状态字段要定义清楚，比如订单状态是待支付、已支付、已取消、已退款，不能让AI随便写几个字符串。
• 自增字段类型要确认，尤其是关键业务字段，如手机号是否支持国际号码，金额是否支持多币种，状态是否可能扩展等。

---

7. 先保留设计文件再建表

7.1 数据库设计文件的重要性

关键观点: 数据库设计文件是数据库结构的来源，应作为版本控制的核心内容。

在数据库设计确认之后，不要直接让AI生成表结构，而是先让AI生成数据库设计文件，如 schema.sql 或当前框架中的 migration 文件。这份文件应保留下来，并提交到 Git 中。

以后你要查有哪些表，每张表有哪些字段，字段类型是什么，表和表怎么关联，都应该能从这里看到。更稳的流程是先生成设计文件，再核对业务对象、表关系、字段和三大范式，确认没问题后再执行建表。

---

7.2 如何与AI讨论设计文件

你可以这样引导AI：

• “请生成数据库设计文件。”
• “这份文件包含哪些表和字段？”
• “表之间的关系是如何描述的？”

这一步的目的是确保设计文件准确反映你的数据库结构，并且可以作为后续开发和维护的依据。

---

8. 写入实施计划再执行

8.1 实施计划的必要性

关键观点: 在执行数据库设计前，应写入实施计划，明确所有细节。

实施计划至少应包括：

• 有哪些业务对象？
• 对象之间的关系是什么？
• 使用什么主数据库？
• 是否需要 Redis？
• 有哪些核心表？
• 每张表负责什么业务？
• 字段名、字段类型、是否必填？
• 表和表如何关联？
• 哪些数据不能物理删除？
• 是否符合前三范式？
• 验收标准是什么？

这些内容写清楚之后，再让AI开始动手。

---

8.2 如何与AI讨论实施计划

你可以这样引导AI：

• “请列出所有业务对象。”
• “请说明每张表的功能和字段。”
• “请确认是否符合前三范式。”
• “请说明验收标准。”

这一步的目的是确保AI完全理解你的需求，并按照规范执行。

---

总结与行动建议

全文总结

本文详细阐述了数据库设计的完整流程，从识别业务对象、确认表关系、选择数据库类型，到设计表结构和字段规范，再到生成设计文件和编写实施计划，每一步都至关重要。良好的数据库设计不仅能提升系统的性能和稳定性，还能显著降低后期的维护成本。

文章强调了与AI协作时的注意事项，特别是在前期阶段不要急于生成表结构，而是要通过逐步引导AI，确保其理解业务逻辑并按照规范进行设计。

---

核心收获

• 数据库设计应从业务流程出发，而非直接生成表结构
• 表之间的关系是数据库设计的关键难点
• 选择合适的数据库类型对项目稳定性和扩展性至关重要
• 字段命名和数据规范直接影响后续开发效率
• 数据库设计文件应作为版本控制的核心内容
• 实施计划应涵盖所有细节，确保AI按规范执行
• 与AI协作时需明确需求，避免模糊描述
• 反范式设计应有充分理由，不可随意使用

---

行动建议

1. 在项目初期，先梳理业务流程，识别核心对象。
2. 与AI协作时，明确业务需求，避免模糊描述。
3. 不要直接让AI生成表结构，而是先生成设计文件。
4. 确保字段命名规范，遵循三大范式。
5. 编写实施计划，明确所有细节后再执行。
6. 将设计文件提交到 Git，作为数据库结构的来源。

---