埃尔法哥哥数据规范之代码表( 二 )
但这种形式也存在一个问题 ， 就是代码变动的问题 。 我们从前面的文章中知道行政区划代码会频繁的变动 ， 如果一个代码表中整合了行政区划代码 ， 会导致整个代码表会频繁变动 。 那么我们整合代码表变得不再是一劳永逸 ， 可能需要频繁的变动 ， 比如每天都要同步代码表 ， 这样也会增加工作量 。 甚至比如某次整合任务失败 ， 那么我们连最简单的性别代码也就失去了 。
所以我建议代码表的数据库设计可以是将一般不变的代码整合到一张代码表中存放 ， 变化的代码表单独存放 ， 这样进行数据整合时只需要及时更新变动的代码即可 。
话说回来 ， 其实数据整合部门在代码上耗费最大精力的恰恰还是那些常用的代码 ， 这些代码也就早有标准规范 。 拿最简单的性别代码来讲 ， 国标《人的性别代码》(GB 2261-1980)中规定：
0 - 未知的性别
【埃尔法哥哥数据规范之代码表】1 - 男性
2 - 女性
5 - 女性改（变）为男性
6 - 男性改（变）为女性
9 - 未说明的性别
当然我们最常用的是1（男性）和2（女性） 。 虽然有这个标准 ， 但在各业务系统中 ， 性别项的表示可谓五花八门 ， 有不填代码的 ， 如记录里填写的就是"男"、"男性"、"女的"等等汉字 ， 或者"MALE"等英文表达 ， 这些是属于不用代码规范的 。 还有用独有代码表的 ， 比如"F"代表女性、"M"代表男性 。 更有甚者 ， 自造的代码表是"0"代表男性、"1"代表女性 。
本文插图
数据整合部门就要耗费精力来解决这些问题 。 当把上述各业务系统中数据整合起来之后 ， 就不能用标准代码来对数据进行翻译 ， 尤其是最后一种情况 ， 如果这样操作恰恰会把数据翻译错 。 这种情况下 ， 我们需要同步每个系统的代码表 ， 然后基于每个系统的代码表对其数据进行翻译 ， 然后再统一对应到标准代码上去 。 如下图：
本文插图
尽管有标准规范可以对照执行 ， 这样的数据整合工作还是非常繁杂琐碎的 。 如果想在后期数据整合信息共享工作上轻松顺畅 ， 那么我们的标准规范一定要全流程覆盖 ， 也就是说标准规范肯定不只是数据整合共享工作的事 ， 更是前端业务系统的事 。
前端业务系统在系统设计时就要按照相应的标准规范进行 ， 在本篇中就要遵照代码标准规范 ， 后面的文章还会讲其他的数据规范 。 代码该采用国标的采用国标 ， 该采用行标的采用行标 。 这样不仅在本业务系统中对数据进行了规范 ， 更有利于后面的数据整合和数据应用 。 因为大家都采用了同一套代码规范 ， 就省却了很多的数据整合工作 。
理想很丰满、现实总是很骨感的 。 前端系统完全遵守相应标准的少之又少 ， 原因也好理解 ， 同样情况下这样做肯定增加了前端系统的设计及开发工作量 。 如果没有一套制度对系统建设的标准问题进行约束的话 ， 很难对现状带来实质性的改变 。
所以在我看来 ， 整个行业的信息化工作需要通盘考虑 ， 尤其是标准规范方面 ， 要做到全行业的统一 。 在数据的最前端 ， 如业务系统等数据采集端就要严格遵守相应的标准规范 ， 不符合标准规范就不能允许其上线运行 。 标准规范要贯穿数据的整个生命周期 ， 从数据采集到数据整合再到数据应用 。
（结尾很突兀 ， 因为接下来还会有类似的内容）
推荐阅读
- 「」儿童节就送阿尔法蛋学习手表，安全贴心又能学习
- -悟空哥哥-618年中大促力来袭，iQOO Neo3应该是你不容错过的5G手机
- 埃尔法哥哥面对用户需求与AI技术之间的不平衡，AI产品经理该如何做？
- 埃尔法哥哥谁说机器学习难？它在这朵云上就没有门槛
- 埃尔法哥哥Python基础语法之“数据应用”
- 埃尔法哥哥Bionumerics软件的多位点VNTR分析
- 埃尔法哥哥一个例子就能读懂大数据，原来数据分析能在这些行业里使用
- 埃尔法哥哥C++程序员的职业生涯规划
- 埃尔法哥哥MAML-Tracker：用目标检测思路做目标跟踪？小样本即可得高准确率丨CVPR 2020
- 埃尔法哥哥U盘插在手机的充电器上会怎么样？为什么？