接过一个「接手维护」的单子：甲方说上一家开发公司不做了，只留下一个数据库账号和一堆表。一百多张表，字段全是英文缩写，ywrq是业务日期还是违约日期？全靠猜。那个项目最后多花了三成的钱在「考古」上。讲这个例子是想说清楚一件事：数据库设计的交付文档，平时看着多余，出事时就是命。
数据字典，最基础也最重要
数据字典就是把每张表、每个字段的含义、类型、取值范围写清楚。好消息是这事成本极低——建表时把COMMENT写规范，用工具一键就能导出。验收时点开任意一张表看备注，十个字段里八个空着，就说明交付打了折扣。所以硬性要求每个字段都有注释，把这条写进合同附件里，比口头强调管用。
ER图和建表脚本
ER图让接手的人十分钟看懂表与表之间的关系，比读一百页文字快。建表SQL脚本要能从头到尾跑一遍还原整个库，包括索引和初始数据。只有一份线上备份而没脚本的，结构变更历史就全丢了，将来谁也说不清哪张表是后加的、为什么加。
还有几样容易被漏掉的
- 枚举值对照表：状态字段的每个值是什么意思，别让接手人翻代码反推。
- 数据初始化说明：哪些是基础数据，哪些是测试数据，上线前要不要清理。
- 变更记录：上线后改过哪些表、加过哪些字段，没有记录的交接等于埋雷。
分享一个验收时的小招数：让开发方现场用数据字典回答你三个问题——退款记录存在哪张表、会员等级字段叫什么、订单来源怎么区分。能秒答，说明文档是真配套的；支支吾吾翻代码，说明文档是临时补的。临时补的文档往往只有个空壳，真到交接时就露馅了。这套问法同样适用于评估在售的成熟系统，买之前先问一轮，总比付款之后再发现问题强得多。
给甲方两条建议：验收清单里明确写上数据字典、ER图、建表脚本、枚举说明四样，少一样都别急着签尾款；验收时随机抽三张表，让你自己公司的技术或者找第三方现场读一遍，能读懂才算合格。比格网络交付项目时，数据库设计文档这四样是标准动作，验收材料齐不齐，最能看出一家开发团队靠不靠谱。
