2.4 命名规范与数据字典

2.4 命名规范与数据字典

本节摘要：命名混乱是隐性维护税，数据字典缺失会让系统在交接时直接失忆。本节给出一套量小实用的 Access 命名约定，并示范如何用一张表承载全库的数据字典，让每个字段的存在理由都有案可查。

表和网络都立好了，还差一件不起眼却决定长期幸福感的事：把规矩写下来。这一节短小但别跳过——它是华彩项目半年后依然运转良好的秘密。

一、为什么命名值得专门一节

想象半年后的一个加班夜：你被叫回来排查"客户消费统计对不上"，打开数据库看到的是 tbl-data001、查询1、查询1_副本、查询最终版、查询最终确定版……此刻你会恨死当初偷懒的自己。命名的作用不是好看，是让系统的结构与业务语义一眼可读，让三个月后的你和接班的同事不必考古。

很多教程会推销冗长的匈牙利前缀法（tblCustomer、frmOrderEntry、qryTopSellers 那一套）。我的看法更务实：Access 对象不多，前缀可要可不要，一致性必须要有。团队约定简即可执行的一套，胜过抄来复杂却三天就放弃的一套。

二、华彩项目实际使用的命名约定

对象命名六条约定

1 全部使用中文或拼音 无空格 必要处用下划线
2 表名 = 业务实体名词 客户 货品 订单 订单明细
3 查询名以动词短语开头 汇总月度销售 待发提醒名单
4 窗体报表名与用途对应 录单窗体 库存看板 月结对账单
5 字段名不缩写到歧义 客户ID 不写作 KHH 或 id1
6 临时对象加前缀 zj废稿 当周清理
​

第 1 条里"无空格"专门提醒一句：对象名带空格在表达式和 SQL 里都得用方括号包起来，[订单 明细].[货品 ID] 这样的引用又难读又易错。第 6 条是我的个人习惯——允许造草稿，但给它们戴上显著标记并定期销毁，避免"副本的副本"野蛮生长。

字段层面还有一条暗规则：同一含义在不同表里必须同名。客户主键在客户表叫 ID，到了订单表就叫客户 ID，而不是客户编号、KehuId、KH 三种写法并存。联接字段同名的好处是查询设计器常常能自动识别匹配关系，报表作者的脑负担也直线下降。

三、数据字典：一行一字段的户口簿

命名解决"叫什么"，数据字典解决"是什么、为什么"。它就是普通的一张 Access 表（华彩项目里命名为数据字典），五个字段起步：

这条"成交单价"的说明看似啰嗦，实际上救过场——新来的同事一度想把成交单价改成实时联带货品单价，多亏字典里注明了"价格快照"的设计意图才避免一次数据事故。字典记录的不是字段是什么，而是当初为什么这么定。

维护节奏建议绑定到一个既有动作上：每次在版本说明里写"本次变更"时，同步增改字典行。单独安排"补文档日"的团队没有能坚持超过一个月的，绑车而行才能持久。

图题：数据字典贯穿设计与维护全程的位置示意

四、顺手收编：说明文档放哪里

除了数据字典，还有零散的口径说明（比如"销售额含不含作废单""月底截止到几号"）。建议在库里建一个说明窗体（只读文本控件堆叠而成），或者干脆链接一篇文本文档进来，总之要让口径解释住在系统内部而不是某个人的邮箱深处。

三、华彩项目的前缀约定与字典实拍

空谈约定不如看实物。华彩项目给对象分类前缀只有五条，贴在设计窗口边上看图即可记住：

对象命名约定节选

tblCustomer   tbl 前缀 = 表     货品表即 tblItem     纯英文下划线分隔
qryOverdue    qry 前缀 = 查询   语义写清业务用途而非技术动作
frmShipment   frm 前缀 = 窗体   报表 rpt 月度汇总 rptSalesMonthly
mcrEntry      mcr 宏            usys 字头 = 私有系统表 不爱打扰使用者
​

两条最划算的小规矩：其一，字段名全库同名同义——客户表的 CustomerID 与订单表里的外键一字不差，建关系时引擎自动对上号，联接查询的 ON 条件闭着眼都能写；其二，禁用空格与拼音缩写的混搭风格，"kehu_mingCheng"这种四不像半年后连作者自己都念不顺。名字是写给半年后的自己和接手的同事看的，可读性就是维护性。

数据字典也不必想象成厚厚一本册子。真正常用的是一张两列核心宽度的速查表——左列字段，右列一句人话解释，打印出来一页纸；详细的约束与刷新策略作为第二层备注挂在表里。下面是华彩字典的三行实拍：

字段速查节录

tblOrder.Status        五枚举 待确认 已确认 已发货 已完成 已作废 改动需走审批
tblOrderDetail.Price   成交时刻的价格快照 禁止与货品表现价做实时联动
tblStock.Qty           可负数 在途调拨期间允许暂时为负 日终对账必须归零或说明
​

再安利一个自带工具：功能区的"数据库文档管理器"，能把所有对象的定义自动导出成一摞报表，拿来当字典底稿再逐行补充"为什么"，比白手起家省一半时间；补齐历史欠账时尤其好用——半天的整理换来之后每次变更都有的对照基准。

三个反模式，见一次躲一次

收尾前把行业里最常见的三种命名病摆出来当镜子。其一拼音缩写漂移：同一张表里同时存在 kh、kehu、customer 三种叫法，三个月后连作者都要靠猜；其二动作命名实体：把查询命名为"计算销售额过程"，它混淆了对象与行为，正确表达是名词性的"销售月度汇总"；其三版本号进名字："客户表新""客户表最新最终版"——版本管理该交给 7.4 的发布机制而不是文件名。三种病的共同解药只有一条纪律：起名时想一句"半年后的我能不能一眼读懂"，答案是否就重来。

五、交接实测：三十分钟读懂度测试

字典好不好，不看你写了多少，看新人读得懂多少。华彩项目验收这套文档用的是一道实操题：请一位没参与开发过该项目的同事，只带着速查表独立回答三个问题——

三道题与及格线

第一题 订单状态一共有哪几种 谁有权改动        答案应在字典枚举行
第二题 报表上的成交价取自哪个字段 为何稳定    应能引述价格快照条目
第三题 库存量字段能否直接改成手工填写         应能指出其由流水推导的约束
​

限时半小时，允许他随手翻看系统界面但不能开口问人。能全对，说明字典真正承担了知识载体的职责；错在哪题，缺陷就在那一段定义。这套测试后来被我们缩写成一句话服务承诺：接手的人不该需要打电话给你。做到这一句，你在 2.1 到 2.4 练的全部功夫才算落袋为安。

本节的约定清单

• 命名的价值在于一致与可读，不在复杂；六条轻约定即可成体系。
• 同义字段跨表同名，为自动联接与协作省心。
• 数据字典五要素：所属对象、字段名、类型、约束、用途；核心是写下"为什么"。
• 文档挂在流程上更新而不是靠自觉，口径说明住进系统内部。

地基工程到此全部完工。下一节做个综合演练，把 2.1 到 2.4 的功夫串成一次完整的建模实操。