作为一个软件开发人员，拿到产品经理或项目经理梳理的 PRD 后，该怎么一步步把数据库设计出来？这里总结了一套可执行的方法论，可以形成 SOP 文档。
Step 1｜通读 PRD，只回答一个问题：系统在“记录什么事实”
目标：搞清楚数据库存在的意义
做法：
- 通读 PRD，不画表、不想字段
- 只提取系统必须长期保存的事实
- 排除：纯计算结果、临时状态、UI 展示信息
输出：一份「系统要存的事实清单」
👉 经验：数据库不是为了存页面，而是为了存不可丢失的业务事实
Step 2｜从事实中抽取“业务实体”（名词建模）
目标：确定有哪些表
做法：
- 把事实里的业务名词圈出来
- 一个稳定名词 ≈ 一个潜在表
- 合并明显重复或强相关的名词
输出：实体列表（如：用户、订单、商品、支付记录）
👉 经验：能被“增删改查”的，几乎一定是实体
Step 3｜为每个实体定义“生命周期”和边界
目标：防止表职责不清
做法：
对每个实体回答：
- 什么时候创建？
- 是否会被删除（物理 / 逻辑）？
- 是否会被修改？
- 是否独立存在，还是依附于其他实体？
输出：实体生命周期说明
👉 经验：生命周期不同的东西，不要放一张表
Step 4｜拆解 PRD 操作流程，反推字段
目标：字段来源于“操作”，而不是拍脑袋
做法：
- 按 PRD 中的每个操作（创建 / 编辑 / 状态变更）问：这个操作需要存什么？
- 把“需要持久化的信息”变成字段
输出：每个实体的字段草稿（不含类型）
👉 经验：一个字段，必须能回答“它是在哪个操作中被写入的？”
Step 5｜设计主键、外键和表关系
目标：把“业务关系”落到结构上
做法：
再明确实体之间关系：
- 谁依赖谁？
- 一对一 / 一对多 / 多对多
- 多对多 → 中间表
输出：表关系图（ER 草图即可）
👉 经验：先有业务依赖关系，再决定外键要不要真的建
Step 6｜补齐工程必备字段（不是 PRD 写的，但必须有）
目标：让表“能活在真实系统里”
做法：
统一补充：
- 主键
id - 审计字段：
created_at/updated_at - 状态字段（而不是大量 boolean）
- 逻辑删除字段（如需要）
输出：工程可用的完整表结构
👉 经验：PRD 不写 ≠ 数据库不需要
Step 7｜基于核心查询设计索引
目标：避免“事后救火”
做法：
- 列出 Top 查询（列表页 / 详情页 / 关联查询）
- 根据
where/order by/join设计索引 - 明确哪些是“高频查询”
输出：索引设计说明
👉 经验：索引是为“SQL”服务，不是为“字段”服务
Step 8｜预留变化空间，验证设计能否演进
目标：防止设计一次性报废
做法：
自问 3 个问题：
- 这个表字段未来会不会爆炸？
- 状态变化是否可扩展？
- 新需求加字段还是加表？
输出：设计风险点 & 未来演进方案
👉 经验：好设计不是“不改”，而是“改得动”