写数据库设计章节，千万别上来就贴一堆表

数据库设计章节经常写成两种极端：一种只有几张字段表，读者看不出表之间怎么关联；另一种只有一张 ER 图，后面没有字段类型、主键外键和说明。真正稳的写法，是先讲概念关系，再落到物理字段。

你可以把这一节拆成三层：ER 图讲表与表的关系，字段表讲每张表的结构，数据库属性图或核心表说明讲重点表为什么这样设计。

ER 图放在前面

ER 图先建立读者的整体认知。它应该展示核心实体和外键关系，例如用户、项目、图表文档、导出记录之间的关系。图后重点解释一对多、多对多和关键外键来源。

如果你的 SQL 里有 COMMENT 注释，工具会优先用注释作为显示名称；如果有 FOREIGN KEY，工具会识别实体关系。也就是说，别只把表名写得漂亮，DDL 里的主键、外键和注释才是图可靠的基础。

字段表负责落地

字段表要写清字段名、类型、长度、是否为空、主键外键和说明。不要用数据库软件截图替代表格。截图里的字体、线条、缩放很难统一，老师也不一定能看清。

一个字段表至少应包含：

字段名	类型	约束	说明
id	bigint	PK	主键
project_id	bigint	FK, NOT NULL	所属项目
created_at	datetime	NOT NULL	创建时间

字段表不是越长越好。普通表按规范列清楚即可，核心表才需要在表后补充设计理由。

属性图适合讲核心单表

数据库属性图会把一张表放在中心，把字段作为属性节点展开，适合解释某张核心表的字段构成。比如“图表文档表”字段比较多，且直接支撑系统核心功能，就可以用属性图帮助读者快速看懂字段分类。

但不要每张表都画属性图。表一多，章节会被图淹没。一般做法是：ER 图讲全局关系，字段表覆盖所有核心表，属性图只挑最关键的一两张表。

设计理由要写在重点表后面

老师看的不是你会不会列字段，而是字段是否有业务理由。例如：为什么导出记录表要保存文件路径？为什么图表文档表要保存 DSL 内容？为什么用户表不能保存明文密码？这些解释能让数据库设计看起来像真实系统，而不是自动生成的表清单。

可以这样写：导出记录表用于追踪每次文档生成结果，因此保存导出类型、文件地址、生成状态和创建时间；其中 document_id 作为外键关联图表文档，便于用户回溯某次导出对应的源图。

和实现章节保持一致

数据库设计不能和后面的实现打架。实现里如果有项目、文档、用户、导出记录，数据库设计章节也应该能找到这些表。反过来，ER 图里出现但代码里完全没有用到的表，会让评阅者怀疑设计不真实。

定稿前建议拿实现里的实体、迁移、SQL 或 ORM 模型对一遍：表名是否一致，外键是否一致，核心状态字段是否一致，删除或合并过的表是否从图里同步更新。