从"他急匆匆地跑来了“来谈一下数据表字段命名
引子
表名、字段名、类名、方法名、属性名、变量名、文件名、配置项...,关于命名,命名规范其中之一是见名知意。在理解需求时,试着抓重点、看本质,据此来命名。切不能强行缩减或随意缩减。许多时候,较长的名称,也比随意简拼的名称易读。如果需要对名称缩减,开发团队应达成一致。如企业id,可以统一enterpriseId,也可以统一使用entId,试想,系统里关于“企业id,同时存在着enterpriseId与entId甚至与merId/merchantId/companyId/qyId/qiyeId,这样的系统会趋向熵增。
下面再罗列一些case:
- “学生成绩表”可以简称“成绩表”,但不能简称“学生表”。
- 平台服务商结算单“可以简称”服务商结算单“,但不能简称”平台结算单“。
- “服务商订单号”,就谈不上简称了。因为在业务上,这是一个完整的词汇。不能简称“订单号”,这会与“系统订单号”存在理解层面的歧义。也不能脑残地简称为“服务商号”,这会与“服务商编号”存在理解层面的歧义。
本文记录开发中的两件事情。
从"他急匆匆地跑来了“来谈一下数据表字段命名
新项目中有个优惠券的功能,优惠券来源于外部的合作通道系统(如微信),我们系统中存储优惠券,会基于使用情况对企业客户进行资金结算。
设计的优惠券表,部分字段见下方:
CREATE TABLE `coupon_batch` ( `batch_id` bigint(20) DEFAULT NULL COMMENT '批次Id', `service_id` bigint(20) NOT NULL COMMENT '服务商id', `enterprise_id` bigint(20) DEFAULT NULL COMMENT '企业id', `channel_batch_id` char(20) NOT NULL COMMENT '第三方优惠券批次号', `batch_name` varchar(100) DEFAULT NULL COMMENT '批次名称', `batch_type` varchar(20) DEFAULT NULL COMMENT '批次类型:NORMAL:代金券批次、DISCOUNT_CUT:立减与折扣、OTHER:其他', `batch_create_time` datetime DEFAULT NULL COMMENT '第三方优惠券创建时间', `begin_time` datetime DEFAULT NULL COMMENT '优惠券开始时间', `end_time` datetime DEFAULT NULL COMMENT '优惠券到期时间', `status` varchar(32) DEFAULT NULL... `reconciliation_status` varchar(20) DEFAULT NULL COMMENT '对账状态-IpsfStateEnum:INIT:未对账、PROCESSING:对账中、SUCCESS:对账完成', ... `create_time` datetime NOT NULL COMMENT '创建时间', `update_time` datetime DEFAULT NULL COMMENT '修改时间', `create_by` varchar(32) NOT NULL COMMENT '创建人', `update_by` varchar(32) DEFAULT NULL COMMENT '更新人', ...
注意其中的 batch_create_time 字段和 create_time 字段,有没有发现 batch_create_time 多少有些不合适呢?
我截图发给开发者小伙。原来,他觉得再加上channel_就显得这个字段太长了(“channel_batch_create_time”的确是够长的),所以就没加。
我举了个栗子:“他急急忙忙的跑来了” 可以简写成“他跑来了”,可以简写成“他来了”。但是,不能简写成“跑来了”、“来了”。
聪明的小伙瞬间明白了。
“服务商结算单”并不是“服务商结算单” - - 抓住需求重点
我们的服务商系统曾经有一个需求是“服务商结算单”。是基于服务商系统里每天的客户交易数据,以月度为单位,给客户生成结算文件。
下面是结算表的表结构。这个表的注释,你觉得应该是什么?
我们的开发者给的表注释“服务商结算单”。这显然不妥。应该叫“客户结算单”。试想,如果你叫“服务商结算单”的话,那么,在服务商系统里给渠道商结算的表,或者是给自由职业者结算的表,或者是给通道结算的表,表注释应该是什么呢?
就是说,我们应该抓重点。服务商给客户结算的表,可以描述为“客户结算表”,但一定不可以描述为“服务商结算表”。
COLUMN_NAME | DATA_TYPE | DATA_LENGTH | NULLABLE | COMMENTS |
ID | NUMBER | 22 | N | 主键 |
MER_ID | VARCHAR2 | 20 | Y | 商户ID |
MER_NAME | VARCHAR2 | 64 | Y | 商户名称(冗余) |
TOTAL_MONTH | VARCHAR2 | 20 | Y | 统计月份 |
TOTAL_AMT | NUMBER | 22 | Y | 费用总额 |
STATUS | VARCHAR2 | 20 | Y | 状态 |
CREATE_TIME | TIMESTAMP(6) | 11 | Y | 创建时间 |
COMPLETE_TIME | TIMESTAMP(6) | 11 | Y | 完成时间 |
FILE_URL | VARCHAR2 | 512 | Y | 结算单文件路径 |
着眼于宏观层面,命名要抓本质,力求通篇一致
作为共享经济服务平台,我们平台的个人用户表是 user,这个表里有个字段,叫 ind_status。表示用户状态。请问,ind 是什么意思?
这个字段的注释是“个人账号状态”。 原来,开发者是根据当时的产品需求进行直译来命名的这个字段名,individual status,简称 ind_status。
有没有想过,对于用户表来说, 个人 跟 用户 有什么区别? 正解是 --------------→ 没区别,是一回事。 不管页面叫什么,既然用户表已经确定是 user 了。那么, 用户状态就应该是 user status,简称 status,人人皆懂。
The End.
当看到一些不好的代码时,会发现我还算优秀;当看到优秀的代码时,也才意识到持续学习的重要!--buguge
本文来自博客园,转载请注明原文链接:https://www.cnblogs.com/buguge/p/17941233