数据字典这个词很多做开发的朋友第一次听到时都会觉得有点虚——听起来像是一本厚厚的说明书跟日常写SQL、调接口没多大关系。但真到了项目里尤其是接手一个跑了三五年、表数量上百、字段命名五花八门的老系统时你才会发现没有数据字典改一个字段就像在雷区里走路谁都不敢保证这一改会不会把某个报表、某个定时任务、某个下游接口给带崩。我自己就经历过一次因为一个status字段的含义在三个模块里理解不一致导致对账数据差了整整一天的量排查了六个小时才定位到问题。从那以后我对数据字典这件事的态度就彻底变了。这篇内容我想把数据字典这件事从头到尾讲透它到底是什么、为什么值得花时间建、怎么从零开始动手做一份能真正用起来的数据字典以及在实际操作中那些文档里不会写的坑。不管你是刚入行的开发、做数据治理的工程师还是带团队的技术负责人都能从中找到可以直接抄作业的部分。我会尽量用大白话配合实际SQL和表格来讲保证你看完就能上手。1. 数据字典到底在解决什么问题1.1 从一个真实的字段歧义说起先讲个我亲身踩过的坑。之前参与过一个电商后台的维护订单表里有个字段叫order_status类型是tinyint。前端展示的时候运营看到的状态有待付款已付款已发货已完成已取消五种。但我在写一个对账脚本时按这个理解去统计已付款的订单金额结果跟财务给的数据对不上。后来翻代码才发现这个字段在数据库里的取值其实是0到7其中2和3都表示某种已付款的中间态只是前端做了合并展示。更麻烦的是另一个模块里还有一张order_ext表里面也有个status字段含义跟order_status完全不是一回事。这就是数据字典要解决的核心问题同一个名字在不同地方含义不同或者同一个含义在不同地方名字不同。前者叫同名异义后者叫异名同义这两种情况是数据混乱的两大根源。数据字典的作用就是把这些约定用文字固定下来让所有人——开发、测试、产品、运营、数据分析——看到同一个字段名时脑子里浮现的是同一个东西。1.2 数据字典和数据库文档的区别很多人会把数据字典和数据库设计文档混为一谈其实两者侧重点不一样。数据库设计文档通常是在项目初期产出的描述的是表结构、字段类型、主外键关系偏向于设计意图。而数据字典更偏向于运行时的真实状态它要回答的问题包括这个字段现在实际存的是什么取值范围有哪些每个取值代表什么业务含义这个字段由哪个模块写入哪些模块读取字段是否允许为空为空时代表什么有没有历史遗留的脏数据打个比方数据库设计文档像是房子的建筑图纸而数据字典像是房子的使用说明书加上物业台账。图纸告诉你墙在哪里说明书告诉你哪个开关控制哪盏灯、哪个阀门对应哪路水。项目跑起来之后图纸往往不再更新但说明书必须跟着实际情况走。1.3 哪些团队最需要数据字典不是所有项目都需要一份正式的数据字典。如果是一个刚起步的小项目三五张表两三个人维护大家口头沟通就够了。但以下几种情况数据字典几乎是刚需表数量超过30张靠脑子记已经不可靠了尤其是字段命名不规范的时候团队人数超过5人沟通成本急剧上升口头约定容易失真有数据分析或报表需求分析师需要准确理解字段含义才能写对SQL系统需要对接外部给第三方提供接口时字段说明是必须的有合规或审计要求需要说明数据来源、流向和敏感级别我个人的经验是当一个项目开始出现这个字段是干嘛的我问问谁谁谁这种对话频率变高时就是该建数据字典的信号了。2. 一份能用的数据字典应该包含哪些内容2.1 表级别信息先搞清楚有哪些表数据字典的第一层是表级别。这一层不需要太复杂但有几个关键信息必须记录清楚。我通常会用一张表来管理字段包括表名、中文名称、所属模块、表类型业务表/配置表/日志表/中间表、数据量级、更新频率、负责人。这里特别说一下表类型这个维度它看起来简单但实际很有用。业务表是核心数据改动要谨慎配置表通常是字典性质的改动影响面小日志表可以定期清理中间表往往是临时性的可能随时废弃。把类型标清楚后面做数据治理或者清理的时候能省很多事。数据量级和更新频率这两个信息主要是给性能优化和容量规划用的。一张千万级的表加索引和一张几万级的表加索引策略完全不同。更新频率高的表做缓存或者读写分离的优先级也更高。2.2 字段级别信息核心中的核心字段级别是数据字典的重头戏。我建议至少包含以下这些列列名说明是否必填字段名数据库中的实际字段名是中文名称业务含义的中文描述是数据类型如varchar(64)、int、decimal(10,2)是是否可空YES/NO是默认值字段的默认值否取值范围枚举值或数值范围是业务含义详细说明这个字段代表什么是写入方哪个模块或服务写入是读取方哪些模块读取否敏感级别公开/内部/敏感/机密是备注历史遗留问题、特殊说明否这张表里我觉得最容易被忽略但又最重要的是取值范围和写入方。取值范围决定了你在写查询条件时能不能穷举写入方决定了你改这个字段时要通知谁。很多线上事故就是因为改了字段但没通知下游读取方导致的。2.3 枚举值字典把魔法数字翻译成人话数据库里大量存在用数字表示状态的字段比如status1表示正常status2表示禁用。这些数字就是所谓的魔法数字对写代码的人来说可能记得住但对做数据分析的人就是灾难。枚举值字典就是专门解决这个问题的。我一般会单独建一张枚举字典表结构大概是字段标识、枚举值、枚举名称、业务说明、是否有效。比如字段标识枚举值枚举名称业务说明order_status0待付款订单已创建未支付order_status1已付款支付成功order_status2部分发货部分商品已发出order_status3已发货全部商品已发出order_status9已取消用户或系统取消有了这张表分析师写SQL的时候直接关联查询就能把数字翻译成中文不用每次都去翻代码。2.4 数据血缘字段从哪来到哪去数据血缘是数据字典里进阶但非常有价值的部分。它描述的是一个字段的数据来源和流向。比如订单表的total_amount字段它的值是由item_amount加上shipping_fee再减去discount_amount计算出来的那么这三个字段就是它的上游。而total_amount又会被同步到数据仓库的订单宽表那就是它的下游。血缘关系在排查数据问题时特别有用。有一次财务反馈某天的销售额异常我顺着血缘往上查发现是优惠券模块的一个计算逻辑改了导致discount_amount算错了进而影响了total_amount。如果没有血缘图这个排查可能要花几倍的时间。血缘不需要一开始就做得很完整可以从核心的几个字段开始逐步补充。手工维护血缘确实累但核心字段就那么几十个投入产出比是划算的。3. 从零开始创建数据字典的完整流程3.1 第一步用SQL把表结构导出来手工一个个字段敲进去是不现实的效率太低还容易出错。正确的做法是先用SQL把现有的表结构导出来再在此基础上补充业务信息。不同的数据库有不同的系统表下面分别说。MySQL里表结构信息主要存在information_schema这个库中。查某个库所有表的字段信息可以用这样的SQLSELECT t.TABLE_NAME AS 表名, t.TABLE_COMMENT AS 表注释, c.COLUMN_NAME AS 字段名, c.COLUMN_TYPE AS 数据类型, c.IS_NULLABLE AS 是否可空, c.COLUMN_DEFAULT AS 默认值, c.COLUMN_COMMENT AS 字段注释 FROM information_schema.TABLES t JOIN information_schema.COLUMNS c ON t.TABLE_NAME c.TABLE_NAME AND t.TABLE_SCHEMA c.TABLE_SCHEMA WHERE t.TABLE_SCHEMA 你的数据库名 ORDER BY t.TABLE_NAME, c.ORDINAL_POSITION;这条SQL跑出来的结果直接导出成Excel或者CSV就是数据字典的雏形。字段注释那一列如果当初建表时写得好这里就能直接用如果没写那就得靠人去补了。SQL Server的话可以用INFORMATION_SCHEMA.COLUMNS或者用系统视图sys.columns配合sys.tables。SQL Server有个好处是扩展属性Extended Properties可以存字段的中文说明用sys.extended_properties能查出来。提示导出的时候一定要带上ORDINAL_POSITION字段顺序因为字段在表中的物理顺序有时候对理解业务逻辑有帮助尤其是那些按时间顺序追加的字段。3.2 第二步补全业务含义和取值范围导出来的表结构只有技术信息业务含义得靠人来补。这一步是最费时间的也是最体现价值的。我的做法是分优先级先补核心业务表再补配置表和日志表先补经常被查询和修改的字段再补边缘字段。补业务含义的时候有几个信息来源可以利用代码里的注释很多字段在实体类或者DAO层有注释可以提取出来前端页面的标签页面上显示的中文名往往就是字段的业务名称问产品和运营他们对业务含义最清楚尤其是状态类字段看历史数据SELECT DISTINCT一下看看实际有哪些值反推含义我特别推荐用SELECT DISTINCT这个方法。比如你不确定user_level字段有哪些取值跑一下SELECT user_level, COUNT(*) AS cnt FROM user GROUP BY user_level ORDER BY cnt DESC;结果出来一看有1、2、3、4、5五个值再结合业务就能推断出是用户等级。如果发现有0或者99这种奇怪的值那可能是历史脏数据正好在数据字典里标注出来。3.3 第三步建立枚举字典和血缘关系枚举字典的建立可以基于上一步SELECT DISTINCT的结果。把每个状态字段的实际取值都列出来然后逐个确认含义。这里有个技巧不要只列当前有效的值把历史上出现过但现在已经废弃的值也列上标注为已废弃。因为历史数据里可能还有这些值分析师如果不了解情况统计时容易出错。血缘关系的建立我建议从核心业务流程入手。比如下单这个流程涉及哪些表、哪些字段支付又涉及哪些把流程串起来血缘自然就出来了。可以用简单的表格记录也可以用专门的工具。对于大多数团队来说一张Excel表格加上清晰的命名规范就够用了。3.4 第四步选择存储和展示方式数据字典做好之后存在哪里、怎么展示也是要提前想清楚的。常见的几种方式各有优劣方式优点缺点适用场景Excel上手快人人会用版本混乱难协作小团队初期Markdown文档可版本控制易diff查询不方便技术团队在线文档协作方便可搜索需要维护权限中大型团队专业数据治理平台功能全可自动化成本高部署复杂大型企业自建Web系统可定制可集成开发维护成本高有专门团队我自己的经验是从Excel或Markdown起步等团队和表数量上来了再考虑升级。不要一上来就搞个大平台维护成本可能比收益还高。关键是内容要准确、要及时更新工具是次要的。4. 让数据字典真正被用起来的几个关键动作4.1 把数据字典接入日常开发流程数据字典最大的悲哀就是做完之后没人看慢慢就过期了。要让它活起来必须接入日常流程。我的做法有这么几个建表或改表时必须同步更新数据字典。这个可以写进团队的开发规范里代码review的时候一并检查。如果用的是Git管理数据字典可以要求DDL变更的PR必须同时修改字典文件。在代码生成或ORM映射中引用数据字典。比如MyBatis的Generator可以根据数据字典生成带注释的实体类这样字段的业务含义就直接体现在代码里了。数据分析师写SQL前先查数据字典。这个习惯需要培养但一旦养成能避免大量因为字段理解错误导致的返工。4.2 用自动化脚本定期校验一致性数据字典和实际数据库之间很容易出现不一致比如有人偷偷加了个字段没更新字典或者改了字段类型没同步。这种问题靠人工检查不现实得用脚本自动化。思路很简单定期跑一遍第3.1节那条导出表结构的SQL跟数据字典里的记录做对比找出差异。差异主要有几种新增了字段、删除了字段、字段类型变了、字段注释变了。把这些差异生成一份报告发给相关负责人确认。这个脚本用Python写最方便用pymysql或者sqlalchemy连接数据库读出来的结果跟Excel或数据库里的字典表做diff。我一般会把它挂到定时任务上每周跑一次有差异就发邮件提醒。4.3 处理历史遗留和脏数据的标注方法老系统里总有一些说不清道不明的字段可能是前人留下的也可能是临时加的。对于这类字段不要强行编一个含义而是如实标注。我通常会用这几种标注待确认含义不明需要找相关人确认已废弃不再使用但历史数据还在历史遗留含义已知但不规范建议新代码不要使用临时字段为某个临时需求加的可能随时删除把这些标注清楚比假装什么都懂要诚实得多也更有用。新人看到这些标注就知道哪些字段要小心哪些可以放心用。4.4 敏感字段的识别与脱敏说明数据字典还有一个重要作用是标识敏感字段。手机号、身份证号、银行卡号、密码这些字段必须在字典里明确标注敏感级别并说明脱敏规则。这不仅是为了合规也是为了安全。我一般会在字段级别信息里加一列敏感级别取值分为公开、内部、敏感、机密四级。公开就是可以对外展示的内部是公司内部可见敏感是需要授权才能访问机密是严格管控。对于敏感和机密字段还要注明脱敏方式比如手机号中间四位掩码、身份证号只保留后四位等。注意敏感字段的识别要全面不要只盯着明显的手机号和身份证。像地址、邮箱、设备号、IP这些在特定场景下也可能属于敏感信息需要根据业务实际情况判断。5. 实战中那些文档不会告诉你的坑5.1 字段注释和实际含义不一致这是最常见也最坑人的问题。建表的时候注释写的是用户状态结果实际存的是用户等级或者注释写1表示正常实际代码里1表示禁用。这种不一致光看数据库是发现不了的必须结合代码和实际数据去验证。我的应对方法是对于核心字段一定要跑一遍SELECT DISTINCT看实际值再结合代码里的判断逻辑确认含义。如果注释和实际不符以实际为准并在数据字典里标注注释有误实际含义为XXX。这个标注很重要能防止后来人再次被误导。5.2 枚举值在代码里硬编码导致字典失效有些团队的数据字典做得很认真枚举值列得很全但代码里还是到处硬编码if status 1。这种情况下一旦枚举值有调整代码和字典就脱节了。更麻烦的是硬编码的魔法数字散落在各个角落改起来容易漏。理想的做法是枚举值统一定义在一处代码和字典都从这里取。但现实是很多老项目做不到那就至少做到数据字典里标注清楚哪些枚举值在代码里是硬编码的改动时需要全局搜索。这个提醒能救命。5.3 多环境数据库结构不一致开发、测试、生产三个环境的数据库结构不一致是另一个大坑。有时候开发环境加了个字段测试和生产没加有时候生产环境为了应急手动改了个字段类型开发环境不知道。这种情况下数据字典到底以哪个环境为准我的建议是以生产环境为准因为那是真实运行的状态。但同时要记录各环境的差异尤其是那些生产有但开发没有的字段很可能是历史遗留需要特别标注。定期做环境间的结构对比把差异消灭掉是数据治理的重要一环。5.4 数据字典更新滞后于需求变更需求变更频繁的项目里数据字典很容易滞后。今天加个字段明天改个枚举如果每次都等有空了再更新字典那字典永远更新不了。解决办法是把更新字典变成变更流程的一部分而不是额外的工作。DDL脚本和数据字典修改放在同一个提交里review的时候一起看这样就不会漏。5.5 大字段和JSON字段的处理现在很多项目会用JSON类型的字段来存扩展信息比如ext_info字段里存一个JSON对象。这种字段在数据字典里怎么描述我的做法是在字段级别信息里标注类型为JSON然后在备注里把JSON的key结构列出来说明每个key的含义。如果JSON结构经常变那就单独维护一份JSON Schema在字典里引用。大字段比如TEXT、BLOB也要特别标注说明存的是什么内容、大概多大、是否会被查询。因为大字段对性能影响大标注清楚能提醒开发者注意。6. 用Python把数据字典自动化起来6.1 自动导出表结构并生成Markdown手工维护数据字典最累的就是同步表结构。用Python可以把这个过程自动化。下面这段代码演示了如何连接MySQL导出所有表的字段信息并生成Markdown格式的文档import pymysql from collections import defaultdict conn pymysql.connect( hostlocalhost, userroot, passwordyour_password, databaseyour_db, charsetutf8mb4 ) sql SELECT t.TABLE_NAME, t.TABLE_COMMENT, c.COLUMN_NAME, c.COLUMN_TYPE, c.IS_NULLABLE, c.COLUMN_DEFAULT, c.COLUMN_COMMENT FROM information_schema.TABLES t JOIN information_schema.COLUMNS c ON t.TABLE_NAME c.TABLE_NAME AND t.TABLE_SCHEMA c.TABLE_SCHEMA WHERE t.TABLE_SCHEMA %s ORDER BY t.TABLE_NAME, c.ORDINAL_POSITION tables defaultdict(list) with conn.cursor() as cursor: cursor.execute(sql, (your_db,)) for row in cursor.fetchall(): table_name, table_comment, col_name, col_type, nullable, default, col_comment row tables[(table_name, table_comment)].append({ name: col_name, type: col_type, nullable: nullable, default: default, comment: col_comment }) with open(data_dictionary.md, w, encodingutf-8) as f: for (table_name, table_comment), columns in tables.items(): f.write(f## {table_name} - {table_comment or 无注释}\n\n) f.write(| 字段名 | 类型 | 可空 | 默认值 | 注释 |\n) f.write(|--------|------|------|--------|------|\n) for col in columns: f.write(f| {col[name]} | {col[type]} | {col[nullable]} | f{col[default] or } | {col[comment] or } |\n) f.write(\n) conn.close() print(数据字典已生成data_dictionary.md)这段代码跑完就能得到一个包含所有表结构的Markdown文档。业务含义的部分还需要人工补充但技术信息已经全了省了大量手工录入的时间。6.2 对比字典与实际结构的差异光生成还不够还得能发现差异。下面这段代码演示了如何对比数据库实际结构和已有的字典文件找出新增、删除和修改的字段import pymysql import csv def get_db_columns(conn, db_name): sql SELECT TABLE_NAME, COLUMN_NAME, COLUMN_TYPE, COLUMN_COMMENT FROM information_schema.COLUMNS WHERE TABLE_SCHEMA %s result {} with conn.cursor() as cursor: cursor.execute(sql, (db_name,)) for table, col, col_type, comment in cursor.fetchall(): result[(table, col)] {type: col_type, comment: comment} return result def get_dict_columns(csv_path): result {} with open(csv_path, r, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: key (row[表名], row[字段名]) result[key] {type: row[数据类型], comment: row.get(字段注释, )} return result conn pymysql.connect(hostlocalhost, userroot, passwordyour_password, databaseyour_db, charsetutf8mb4) db_cols get_db_columns(conn, your_db) dict_cols get_dict_columns(data_dictionary.csv) db_keys set(db_cols.keys()) dict_keys set(dict_cols.keys()) print( 数据库有但字典没有新增字段) for key in sorted(db_keys - dict_keys): print(f {key[0]}.{key[1]} ({db_cols[key][type]})) print(\n 字典有但数据库没有已删除字段) for key in sorted(dict_keys - db_keys): print(f {key[0]}.{key[1]}) print(\n 类型或注释不一致 ) for key in sorted(db_keys dict_keys): if db_cols[key][type] ! dict_cols[key][type]: print(f {key[0]}.{key[1]} 类型: 数据库{db_cols[key][type]} 字典{dict_cols[key][type]}) if db_cols[key][comment] ! dict_cols[key][comment]: print(f {key[0]}.{key[1]} 注释: 数据库{db_cols[key][comment]} 字典{dict_cols[key][comment]}) conn.close()这个脚本可以挂到定时任务里每周跑一次把差异报告发给团队。坚持一段时间后数据字典和实际结构的一致性会明显提升。6.3 把字典转成Excel方便非技术同学使用技术同学喜欢Markdown但产品、运营、财务这些同学更习惯Excel。把Markdown表格转成Excel可以用pandas轻松实现import pandas as pd # 假设已经从数据库读出了数据构造DataFrame data { 表名: [order, order, user], 字段名: [id, order_status, id], 中文名称: [订单ID, 订单状态, 用户ID], 数据类型: [bigint, tinyint, bigint], 业务含义: [订单唯一标识, 订单当前状态, 用户唯一标识] } df pd.DataFrame(data) # 写入Excel每个表一个sheet with pd.ExcelWriter(数据字典.xlsx, engineopenpyxl) as writer: for table_name, group in df.groupby(表名): group.to_excel(writer, sheet_nametable_name, indexFalse) print(Excel已生成数据字典.xlsx)这样生成的Excel每个表一个sheet非技术同学打开就能看懂也方便他们补充业务含义。7. 数据字典的长期维护与团队协作7.1 明确责任人和更新机制数据字典要长期有效必须有人负责。我的建议是每个模块指定一个数据负责人负责该模块相关表的字典维护。整体上再有一个数据管理员做统筹和审核。更新机制上把字典更新纳入需求开发和变更流程而不是单独的一件事。具体来说可以这样约定任何DDL变更建表、加字段、改字段、删字段的提交必须包含数据字典的对应修改。代码review时如果发现DDL变更但字典没改直接打回。这个规则执行一段时间后就会变成团队的习惯。7.2 版本管理与变更记录数据字典本身也需要版本管理。用Git管理Markdown格式的字典是最方便的每次修改都有记录可以追溯谁在什么时候改了什么。如果用的是Excel至少也要保留历史版本或者用在线文档的版本历史功能。变更记录里我建议记录这几个信息变更时间、变更人、变更内容、变更原因。尤其是变更原因能帮助后来人理解为什么会有这个改动。比如因为业务调整订单状态新增了部分退款状态这样的记录比单纯写新增枚举值4有用得多。7.3 新人入职时的数据字典培训数据字典还有一个很好的用途是新人培训。新人入职时让他先花半天时间读一遍数据字典对系统的数据模型有个整体认识比直接扔给他代码看要高效得多。我通常会安排一个环节让新人根据数据字典画出核心业务的数据流图画得出来说明他理解了画不出来就针对性地讲解。这个做法还有个额外好处新人往往会发现字典里一些表述不清或者过时的地方正好借这个机会修正。7.4 定期评审与优化数据字典不是做完就一劳永逸的建议每季度做一次评审。评审的内容包括字段含义是否还准确、枚举值是否有变化、血缘关系是否需要更新、敏感级别是否合适、有没有可以合并或废弃的字段。评审的时候拉上产品、开发、数据分析一起各方视角不同能发现单方面发现不了的问题。我参加过的一次评审就发现有两个字段其实是重复的一个是历史遗留一个是新加的合并之后省了不少事。8. 关于工具选型的一些个人看法8.1 从Excel到专业平台的演进路径工具选型这件事我的观点是匹配当前阶段就好不要过度设计。团队五个人、二十张表的时候用Excel完全够用搞个专业平台反而是负担。等到了五十张表、十个人的时候可以考虑用在线文档或者轻量的自建系统。上百张表、跨多个团队的时候才需要考虑专业的数据治理平台。演进路径大致是Excel → 在线文档/Markdown → 自建轻量系统 → 专业平台。每一步的升级都是因为当前方式遇到了明显的瓶颈而不是因为别人都在用。8.2 自建系统的取舍有些团队会选择自建一个数据字典管理系统。自建的好处是能完全贴合自己的需求比如跟内部的权限系统打通、跟CI/CD流程集成。但坏处也很明显开发和维护成本高容易变成做完就没人维护的烂尾项目。如果决定自建我的建议是从最小可用版本开始先做一个能查询、能搜索的页面把数据字典的内容录进去。不要一上来就搞血缘图、影响分析这些高级功能。等基础功能用起来了再根据实际需求迭代。我见过太多自建系统功能做了一大堆结果基础数据都没录全最后不了了之。8.3 开源方案的评估要点开源的数据字典或数据治理方案也有不少评估的时候我主要看这几点部署复杂度、是否支持你的数据库类型、元数据采集是否自动化、社区是否活跃、文档是否齐全。部署复杂度是第一位的如果一个方案部署就要折腾好几天那大概率用不起来。元数据采集的自动化程度也很关键手工录入的方案基本都会失败。8.4 什么情况下不值得投入最后说说什么情况下不值得在数据字典上投入太多。如果项目是短期的、一次性的做完就扔那没必要建字典。如果表数量很少、团队很小、大家沟通顺畅那口头约定加简单的注释就够了。如果项目处于快速试错阶段结构天天变那建字典的收益也有限不如等结构稳定了再建。数据字典的本质是降低沟通成本和变更风险当这两个成本不高的时候投入就不划算。判断的标准很简单问问团队里有没有人因为字段理解错误而踩过坑如果有那就值得投入。9. 一个可以直接抄作业的最小可行方案说了这么多最后给一个我自己在用的最小可行方案适合十人以内、五十张表以内的团队直接抄就行。第一步建一个Git仓库里面放一个data_dictionary.md文件按表分章节每个表一个Markdown表格包含字段名、中文名称、类型、可空、默认值、取值范围、业务含义、备注这几列。第二步写一个Python脚本参考第6.1节的代码从information_schema导出表结构生成Markdown骨架人工补充业务含义部分。第三步写一个对比脚本参考第6.2节的代码每周跑一次把数据库和字典的差异发到团队群里。第四步在开发规范里加一条DDL变更必须同步更新data_dictionary.mdreview时检查。第五步每季度做一次评审拉上产品和数据分析一起过一遍。这套方案的成本很低一个脚本加一个文档但效果很好。我带的团队用这套方案跑了两年多字段理解错误导致的问题基本绝迹了。等哪天这套方案撑不住了再考虑升级工具也不迟。数据字典这件事说到底是个磨刀不误砍柴工的活。前期花点时间建起来后面省下的排查时间和沟通成本是几十倍甚至上百倍的回报。我自己的体会是越是老系统、越是多人协作的项目数据字典的价值越大。如果你现在的项目还没有不妨从今天开始先导出表结构把核心表的字段含义补上慢慢积累总比一直裸奔强。
