一、引言
在进行软件开发的时候,经常需要用到下拉选项,那么这些选项值从哪里来呢?如何存才合适呢?如果有过相关经验的同学肯定会有关于这方面的思考。
如果直接将枚举值写在代码中,将会有以下弊端:
1、复用问题,例如下图的年级,老师、学生均会有年级和班级,如果固定写在代码里,将需要写多份重复的代码。
2、维护困难,例如下图的年级新增了2021级,不仅需要对硬代码进行修改,而且容易导致数据不一致的问题,例如老师页面的改了,学生页面或者其它的页面没有同步修改。
二、配置表解决
对于相对固定、不经常更新的枚举值,可以设计一张配置表集中管理这些值,需要使用的时候直接从表中取值。数据只存一份,后续维护的时候也只需要简单地修改一下数据。
可以对比一下配置表和硬代码方式实现的维护性,如果写在硬代码中,那么客户需要变更枚举值的时候,我们需要精准地修改代码,提交,再重启我们的项目,在真实的使用场景中,应用重启是一个很敏感的操作,必须要申请版本,在指定时间做这个操作。而配置表的方式,只需要运维执行一下sql脚本修改数据即可,不会影响到正常的使用。
下面用一个例子进行演示:
1、表设计
字段 | 类型 | 索引 | 注释 |
---|---|---|---|
uuid | varchar(64) | pk_ | uuid |
theme | varchar(64) | idx_ | 参数名 |
param_key | varchar(64) | idx_ | 键值 |
param_value | varchar(1024) | 值 | |
expir_time | datetime | 过期时间 | |
status | bigint | 状态 |
theme字段主要用于分类,例如学生信息,主题是student_info,里面包含性别sex、班级class等枚举值,这些就是param_key。
param_value储存枚举值,varchar类型大小相对固定,可以考虑使用blob类型,但是查询效率会降低很多,如果要使用,建议使用redis做缓存。
theme和param_key作为查询条件,建立索引可以大大提高查询效率
2、使用
例如一个压缩后的json字符串,我们可以存到数据库中
[{"courseList": null,"id": 1001,"name": "2018级"},{"courseList": null,"id": 1002,"name": "2019级"},{"courseList": null,"id": 1003,"name": "2020级"}]
我们直接查询出来的时候是一个转义后的字符串,正常是不能直接使用的,前端或者后端将字符串转为json对象即可
{
"code": "0",
"msg": "成功",
"data": "[{\"courseList\": null,\"id\": 1001,\"name\": \"2018级\"},{\"courseList\": null,\"id\": 1002,\"name\": \"2019级\"},{\"courseList\": null,\"id\": 1003,\"name\": \"2020级\"}]"
}
java可以使用JSON.parse()来转义,转换后可以得到结果
{
"code": "0",
"msg": "成功",
"data": [
{
"name": "2018级",
"courseList": null,
"id": 1001
},
{
"name": "2019级",
"courseList": null,
"id": 1002
},
{
"name": "2020级",
"courseList": null,
"id": 1003
}
]
}
三、redis缓存
在上面有讨论到param_value使用varchar(1024)并不理想,如果数据过大需要重新扩容,并且对小数据会造成大量的空间浪费,故推荐使用blob字段,使用redis做为缓存。
使用redis时,就有必要去考虑数据同步问题,经典的做法是手动同步和定时同步一起使用,当主机重启、紧急情况的时候就可以通过脚本去同步数据,定时同步主要是解决缓存击穿、缓存穿透、替换原则等带来的数据丢失风险,维护数据的一致性和完整性
这里就不展开用法讲解了,大家加油!