定义数据字典名,或者常量值时,用字符串还是用数字?

口吞山河 发布于 2017/02/23 18:18
阅读 524
收藏 0

项目里的数据值总会用到各种状态,各种类型,比如用户冻结,用户注销,用户锁定,充值记录又有支付宝充值类型、微信充值类型等。

对于这些数据通常会定义常量来表示,那么问题来了,大家一般使用字符串,还是数字来做常量呢?

我个人觉得字符串看着直观容易理解,但是数据长了,要好几个字符;数字呢简洁,一般2位数字也够表示了,存储或执行性能也好。

加载中
2
中山野鬼
中山野鬼

给你个建议,是用字符串。哈。我的理由如下:

1、无论数字还是字符串,从应用角度都是“符号”,对应都有“值”。但字符串的表述形式更弹性,更易于面向业务需求。

2、数字唯一的优势是处理快,存储占用小。而这些是可通过扩大底层系统规模和优化处理方法来弥补的。

3、数字的缺点是值域和存储格式有关,使得你不得不兼顾考虑因为“溢出”导致的额外处理工作,这从系统设计角度是有问题的。额外处理工作是指,不与系统设计目标有关,且逻辑无法受到系统设计约束,导致系统设计的内在逻辑无法自洽。

哈,第三个观点,像shit一样晦涩,我简单说个例子。

1、一个公司需要在另外一个城市组织新团队,现有团队中,如果人人都是有家有口,无法长期出差的,那么会引发一堆家庭问题需要公司来协调,最终才能找到一个能在前期常驻新城市的人员来带队。 公司业务发展类似系统,而员工本身确实属于公司这个系统组成,但员工的家庭问题,是和这个系统无关的。公司的业务发展与运营和家庭的日常生活,没有逻辑关联,因此你无法通过公司发展的一些远期愿景来尝试修正员工家庭的生活轨迹。难道逼员工离婚。哈。这就是额外处理工作对系统设计带来的内在逻辑无法自洽。你会发现各种和企业发展无关的屁事,却作为企业具体开展工作的必要条件。

当然数字方式有自己的优势,上面也说过了。处理快,存储小。不过这个完全可以采用按存储特性进行二次处理的思路来优化。简单说,归档的数据和终端表现的数据仍然是字符串。而在系统内部,高频发生的数据处理工作的内容则转化成数字。在需要做编码调整时,对归档的数据重新调整并对系统类所有对应数据进行数字格式的调整,保证系统内数据的一致性。

0
Lyzh_
Lyzh_

说这话的你一定没用过C++。老实说,我建议你用代替符,别用字符串!因为……用字符串效率要低好几个档次(散列表除外

0
中山野鬼
中山野鬼

引用来自“Sentence”的评论

说这话的你一定没用过C++。老实说,我建议你用代替符,别用字符串!因为……用字符串效率要低好几个档次(散列表除外

这是局部设计的观点,不是系统设计的观点。 真需要考虑局部数据处理速度的情况,完全可以进行算法优化来替代的。哈。

0
口吞山河
口吞山河

引用来自“Sentence”的评论

说这话的你一定没用过C++。老实说,我建议你用代替符,别用字符串!因为……用字符串效率要低好几个档次(散列表除外

是呢,C++只有大学时学过,还真没拿来开发过项目,也没在工作中用过。现在一直是JAVA。这个”代替符”还真不懂了

Lyzh_
Lyzh_
比如说枚举什么的,当然还可以用散列表,毕竟散列表效率也超高的,最近在研究Python虚拟机,刚好想到这点
0
ManderSF
ManderSF

字典表多设计几个字段  你说的这种情况应该都可以得到解决的吧   

0
尚浩宇
尚浩宇

从性能上,应该使用数值,单独备注字段去存解释,从设计上,数据库是给系统用的,不是让你拿着数据库就能看明白到底是什么东西的

0
飞炀
飞炀

我们公司数据字典一般会用枚举类,这样序列化可以存储为数字,加载后可以直接进行一致性比较,还可以直接获取到对应的文本显示。

老菜鸟0217
老菜鸟0217
就是翻数据库查问题时,一堆数字不直观。
0
蓝水晶飞机
蓝水晶飞机

订单状态定义表:

程序里面用枚举:

表设计:

主键,整型,唯一,面向数据的

代码,字符串,唯一,面向开发者的

名称,字符串,非空,面向用户的

 

0
Lyzh_
Lyzh_

引用来自“Sentence”的评论

说这话的你一定没用过C++。老实说,我建议你用代替符,别用字符串!因为……用字符串效率要低好几个档次(散列表除外

引用来自“中山野鬼”的评论

这是局部设计的观点,不是系统设计的观点。 真需要考虑局部数据处理速度的情况,完全可以进行算法优化来替代的。哈。

还有一个比较折中的方案,就是用散列表,直接映射Key

返回顶部
顶部