前面讲了前端骨架。在之前的视频里我也说过：如果你的项目涉及前端、后端和数据库，我建议先把前端主要流程打磨成型，再开始做数据库设计。
因为前端成型之后，你会更清楚用户有哪些操作、页面需要哪些数据、业务里到底有哪些对象。这个时候再设计数据库，就不是让 AI 凭空猜表。
所以这一小节，我们开始讲讲数据库设计。
很多人一上来就跟 AI 说：帮我建个数据库，我要存用户、订单、商品这些数据。
这一步看起来快，但后面很容易乱。
在一个需要上线、需要多人使用的项目里，数据库决定了数据怎么存、接口怎么查、页面怎么展示、后台怎么统计。如果数据库设计乱了，后面前端、后端、权限、订单、支付、统计都会被拖进去。
更麻烦的是，数据库乱不只是代码难改，还会影响后期维护成本和运营成本，因为一个设计得很差的数据库，一旦数据量大了，查询是很慢的。以前圈子里有个梗：数据库查询慢了，就加钱上好服务器。
但真正稳的做法，不是等慢了再砸钱，而是一开始就把数据库设计清楚。
所以涉及数据库的项目，不要让 AI 上来就直接建表，而是要先做数据库设计。
一、先从业务流程里找对象
数据库一定是从业务里长出来的。
第一步不是问 AI 要几张表，而是让 AI 根据你的页面、用户流程和核心功能，先整理项目里有哪些业务对象。
比如电商项目，常见对象有用户、商品、订单、支付记录、收货地址。
内容平台，常见对象有用户、文章、评论、点赞、收藏。
后台系统，常见对象有用户、角色、权限、操作日志。
预约系统，常见对象有用户、服务项目、预约记录、时间段、门店。
这些业务对象，后面大概率就是数据库里的核心表。
如果你的前端已经比较清楚，就可以让 AI 根据页面反推数据。比如注册登录需要用户信息，订单列表需要订单信息，商品详情需要商品信息，评论区需要评论信息，权限管理需要角色和权限信息。
如果你的项目没有前端，或者前端还没做完整，也可以让 AI 从立项文档和功能说明里推。但这个时候你要多和 AI 讨论，因为你的需求文档不一定写得细，AI 很容易漏掉业务对象。
到这一步，先别急着建表。
你要先让 AI 说清楚：项目里有哪些核心对象，每个对象对应什么业务场景。
二、确认对象之间的关系
对象找出来之后，再确认关系。
数据库最容易乱的地方，往往不是少一两个字段，而是表和表之间的关系没想清楚。
比如用户和订单，一般是一个用户可以有多个订单，一个订单只属于一个用户。那订单表里通常就需要 user_id。
比如文章和评论，一篇文章可以有多条评论，一条评论属于一篇文章，也属于一个用户。那评论表里通常需要 article_id 和 user_id。
比如用户和角色，如果一个用户只有一个角色，可以在用户表里放 role_id。如果一个用户可以有多个角色，就需要用户角色关联表。
你要让 AI 解释清楚：
每张表代表什么对象。
哪些表之间有关联。
是一对一、一对多，还是多对多。
关联字段放在哪张表里。
为什么这样设计。
这一步的目的，是确认 AI 理解的是你的业务，而不是自己猜了一套表结构。
你可以信任 AI 的技术判断，但前提是你要把业务讲清楚，并且让它把设计理由解释出来。
三、确定数据库服务
对象和关系确认之后，再确定用什么数据库。
常见业务项目，优先考虑 MySQL 或 PostgreSQL。
后台系统、SaaS 工具、内容平台、订单系统、电商项目，这类有用户、有内容、有权限、有交易记录的项目，用关系型数据库会更稳。
如果只是本地小工具、桌面应用、轻量数据存储，可以考虑 SQLite。
Redis 也经常出现，但它通常不是主数据库。
Redis 更多是用来做缓存、登录状态、验证码、限流、队列、临时数据，用来减轻主数据库压力，提高并发能力。
除非你的项目明确有缓存、队列或高并发需求，否则不要一开始就把 Redis 当成必选项。
你要让 AI 说清楚：主数据库用什么，为什么用它，要不要 Redis，本地开发和线上部署怎么处理。
对于不懂技术的人来说，优先选择成熟、常见、文档多、AI 熟悉的方案。
四、设计表结构和字段规范
数据库服务确定之后，再开始设计表结构和字段。
这里要用数据库设计里的三大范式做基本校对。
你不需要背得很学术，但要知道它们解决的是什么问题。
第一范式，字段要原子化。
一个字段只存一个明确含义。手机号就放手机号，地址就放地址，备注就放备注，不要把手机号、地址、备注拼成一个大字符串。
第二范式，字段要围绕当前这张表的主对象。
用户表主要放用户信息，订单表主要放订单信息，商品表主要放商品信息。
比如订单表可以通过 user_id 关联用户表，就不要把用户头像、昵称这类和订单本身无关的信息反复塞进订单表。
但有些订单信息需要保留当时的快照，比如收货人姓名、收货手机号、收货地址。因为用户后面改了地址，历史订单不能跟着变。这种重复是有业务原因的，必须让 AI 说明清楚。
第三范式，字段之间不要互相依赖。
比如用户表里已经有 city_id，城市名称可以从城市表里查，就不要随手再存一份 city_name，否则城市名称一改，两边可能不一致。
三大范式的核心，不是把表拆得越多越好，也不是字段越少越好，而是让数据更清楚、少重复、少冲突。
复杂业务为了查询性能，确实可能会做反范式设计。但这种情况必须让 AI 先说明原因，不能随便重复存字段。
你可以直接告诉 AI：数据库设计尽量符合前三范式，避免字段混乱、重复存储和不清晰的数据依赖。如果为了查询性能需要反范式设计，必须先说明原因。
五、常见字段要提前规范
表结构设计时，还有一些常见字段要提前规范。
以用户表为例，常见字段可能有：
id
username
phone
password_hash
last_login_ip
created_at
updated_at
last_login_at
数据库字段建议用英文下划线命名，后面写代码、写 SQL、接接口都会更方便。
id 是主键，用来唯一标识一条数据。
created_at 是创建时间。
updated_at 是更新时间。
这两个时间一般由程序或数据库自动维护。
如果有些数据不能真的删除，比如订单、支付记录、财务数据，可以考虑加 deleted_at 做软删除。
也就是前台看不到了，但数据还在数据库里，方便后台审计和后续排查。
另外几个坑也要提前避开。
密码不要存明文，要存 password_hash。
金额不要随便用浮点数，可以用分为单位的整数，或者用数据库里的精确数字类型。这个时候你要说清楚货币是什么，最多几位小数。
状态字段也要定义清楚，比如订单状态是待支付、已支付、已取消、已退款，不能让 AI 随便写几个字符串就结束。
关于字段，还有最重要的一点就是字段类型，这个就偏专业了，所以字段类型可以让 AI 推荐，但关键业务字段一定要确认。比如手机号是否支持国际号码，金额是否支持多币种，状态后面会不会扩展，这些都要提前说清楚。
六、先保留设计文件，再建表
数据库设计确认之后，不要直接让 AI 连数据库建表。
先让 AI 生成数据库设计文件，比如 schema.sql，或者当前框架里的 migration 文件。
这份文件一定要保留下来，并且提交到 Git。
因为它是数据库结构的来源。
以后你要查有哪些表、每张表有哪些字段、字段类型是什么、表和表怎么关联，都应该能从这里看到。
更稳的流程是：先生成数据库设计文件，再核对业务对象、表关系、字段和三大范式。
确认没问题，再执行建表。
后面要改字段，也先改 schema 或 migration，再执行变更。
这条也可以写进 agent 宪法：
任何数据库结构变更，必须先修改 schema 或 migration 文件，说明变更原因，再执行数据库操作。
七、写进实施计划，再让 AI 动手
前面这些确认之后，再写进实施计划。
实施计划里至少要写清楚：
有哪些业务对象。
对象之间是什么关系。
使用什么主数据库。
要不要 Redis。
有哪些核心表。
每张表负责什么业务。
字段名、字段类型、是否必填。
哪些字段唯一。
哪些字段可以为空。
表和表怎么关联。
哪些数据不能物理删除。
是否符合前三范式。
验收标准是什么。
这些写清楚之后，再让 AI 开始动手。
但注意，这一步不要一口气写完整业务。
目标只是先把数据库基础结构跑通。
比如数据库能连接，核心表能创建，migration 能执行，能插入测试数据，能查询测试数据。
这就够了。
数据库跑通之后，先提交一次 Git，再开始写接口和业务功能。
八、最后
涉及数据库的项目，不要让 AI 上来就直接建表。
先从业务流程里找对象。
再确认对象之间的关系。
然后确定数据库服务。
接着设计表结构和字段规范。
再生成数据库设计文件。
最后才让 AI 建表，并跑通数据库基础结构。
如果你不知道自己的项目该怎么拆业务对象，可以在评论区留言“数据库对象”。
如果你已经让 AI 建过表，但现在字段很乱、表关系看不懂、接口对不上数据库，可以留言“数据库乱”。
