buguge - Keep it simple,stupid

知识就是力量,但更重要的,是运用知识的能力why buguge?

导航

从"他急匆匆地跑来了“来谈一下数据表字段命名

引子

表名、字段名、类名、方法名、属性名、变量名、文件名、配置项...,关于命名,命名规范其中之一是见名知意。在理解需求时,试着抓重点、看本质,据此来命名。切不能强行缩减或随意缩减。许多时候,较长的名称,也比随意简拼的名称易读。如果需要对名称缩减,开发团队应达成一致。如企业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.

posted on 2024-01-02 20:15  buguge  阅读(78)  评论(0编辑  收藏  举报