数据字典是系统里每张表、每个字段的说明书。一共七列：表名、字段名、类型、中文含义、取值范围、谁维护、最后更新。验收时抽 3 张表、每表 5 个字段，让对方当场说出含义，说不出来就不签字。
没有这份东西，系统就只认原班人马。
换个运维、换家外包、原厂项目经理离职，新人打开数据库，看到 t_ord_mst 里的 f_st，只能猜。猜错一次，一张报表的口径可以错一个月。
数据字典就是系统的药品说明书。药名、成分、每片多少毫克、什么人不能吃、哪个厂生产、批号到哪年，少一项都不敢吃。字段也一样，少一列就有人要猜。
猜的代价不在当天。三个月后对账平不了，翻记录发现是「金额存的是分，报表按元读的」。这时候人已经换了，谁都不认。
对账的场景最直接。两个系统数对不上，第一件事是问「这两个字段是不是一个意思」。有字典，五分钟；没有字典，两家厂商互相等对方出说明。
换供应商时更明显。新团队进场第一周要读系统。有字典，两周能接手；没有字典，报价里会多一项「系统梳理」，几万块，你还不好还价。
七列，一列都不能省。
第一列，表名。要带库名或模式名。两张库里有同名表，是常见的事，只写表名，运维会改错那一张。
第二列，字段名。照抄数据库里的写法，别美化。字典和库对不上，这份文件就废了。
第三列，类型。varchar(32)、decimal(10,2)、datetime，写全。金额用浮点数存，四舍五入差几分钱，这种错最难查。
第四列，中文含义。一句话说清是什么，不要只写「状态」。要写「订单状态：待付款、已付款、已发货、已取消、已退款」。
第五列，取值范围。枚举值全列出来。数字写单位和精度，金额写清是元还是分。日期写清时区，跨时区的系统这里最容易错。
第六列，谁维护。写岗位加姓名，再写业务归属部门。只写「技术部」，等于没写，出事找不到人。
第七列，最后更新。写日期，配一条变更记录：谁改的、改了什么、为什么改。
| 列 | 省了会怎样 |
|---|---|
| 表名 | 改错同名表，数据串库 |
| 字段名 | 字典与库不一致，整份作废 |
| 类型 | 金额、日期算错，事后才发现 |
| 中文含义 | 新人靠猜，需求提错 |
| 取值范围 | 统计漏掉一种状态，数对不上 |
| 谁维护 | 改数据没人认，互相推 |
| 最后更新 | 不知道哪版可信，全都不敢用 |
谁写这份东西。
前三列由开发写，从库里导，不要手打。中文含义、取值范围两列由业务方确认，两边签字。
常见做法是全交给开发。开发理解的「已支付」和财务理解的「已到账」不是一回事，字典写了也白写。
验收怎么抽。
随机抽 3 张表，每张抽 5 个字段，一共 15 个点。让对方的技术负责人当场说：这个字段是什么、有哪些取值、哪个业务在用。
第二步，让他在系统里查出这个字段的实际取值。字典写状态有 5 种，库里查出 7 种，说明字典过期了。这一步比背含义更难糊弄。
第三步，打开数据库比对结构。字典写了 24 个字段，库里 27 个，直接不通过，不用再问。
让对方现场导出表结构，一句查询就够。他要是不肯给库权限，就给这个结果，别给截图。
select column_name, data_type, column_comment from information_schema.columns where table_schema = '库名' and table_name = '表名';
判定线写死，别留解释空间。15 个点错 2 个以上不通过；字典与库结构不一致不通过；「最后更新」早于最近一次上线日期，视为没维护。
验收条款可以这样写。乙方应随系统交付《数据字典》，覆盖全部业务表。列明表名、字段名、数据类型、中文含义、取值范围、维护责任人、最后更新日期。甲方随机抽 3 张表、每表 5 个字段现场质询；错误 2 个以上，或字典与库结构不一致，验收不通过。
条款里「全部业务表」四个字要盯住。很多字典只写主表，字典表、日志表、中间表一概不写。真出事，问题常出在这几张表上。
覆盖范围可以这样谈：核心业务表全写，配置表和字典表跟着写。日志表、临时表可以不写，但要在文档里列一张「未覆盖清单」，别让人以为漏了。
格式也说清。Excel 或在线表格都行，别只给 PDF。PDF 搜不了、改不了，第二年就是一份没人打开的附件。
交完之后怎么不烂掉。
表结构一变，字典要跟着变。做法是把它挂进变更流程：改表的申请单里有一栏「字典已更新」，没勾这一栏，变更不批。
再设一次对账，每季度一次。拿字典和库里的实际结构比一遍，字段数、类型、注释三项对不上就补。一次半小时，比事后查账便宜。
换人交接时，字典放清单第一项。新人第一周的任务不是改代码，是拿字典把三张核心表讲一遍，讲不清就是没看懂。
依据是有的。GB/T 8567 是软件文档的国标。1988 版单独设了《数据库设计说明书》一章，其中 13.4.1 就叫「数据字典设计」。
原话大意是：对数据库设计中涉及的数据项、记录、文卷、模式、子模式，一般要建立数据字典。用途是说明这些项目的标识符、同义名及有关信息。这一版已被 2006 版代替。
现行的 GB/T 8567-2006 把它拆成两份文档：《数据需求说明》和《数据库（顶层）设计说明》，并规定了各自的内容与格式。文档交哪些，合同里可以直接引这个标准。
《政府采购需求管理办法》第二十四条要求，验收标准要包括所有客观、量化指标。15 个抽查点、错 2 个不通过，就是可量的标准，不是「文档齐全、内容完整」这种话。
三个坑，见到就退回。
- 字典从代码注释导出，中文含义一栏还是英文。
- 只覆盖主表，字典表、日志表、中间表不写。
- 上线后没人维护，第二年就对不上了。
还有一处常被忽略：字典验收完要存到甲方自己的地方。存在乙方的网盘里，合同一结束，链接就失效了。
系统小也别跳过。只有三张表的系统，字典一页纸，半小时写完。等长到三十张表再补，就是一周的活。
成本这件事也说一句。做一份完整字典，按经验要两到四个人日，看表的数量。这笔钱在上线前花，是几千块；在换人之后花，是重新读一遍系统的价钱。
数据字典不贵，一份 Excel 就够。贵的是没有它的时候，每换一个人，全组重猜一遍。
