业务中的字典表的MySQL实现方案

举报
JavaEdge 发表于 2021/06/03 23:16:32 2021/06/03
【摘要】 为什么需要字典表? 某些变量在多个地方使用,而且一般固定,但随系统升级和后期变化,可能需要改变,如果这些变量写死在代码里面将会变得难以维护,所以要将其从代码中抽离。 一般的业务系统客户端与用户交互的时候都会使用下拉框组件,对于某些比较固定的值的下拉组件的数据来源一般都是比较固定的文本。 实现方案 有的人使用枚举或Constants实现,这种情况下在量少的前提是没...

为什么需要字典表?

某些变量在多个地方使用,而且一般固定,但随系统升级和后期变化,可能需要改变,如果这些变量写死在代码里面将会变得难以维护,所以要将其从代码中抽离。

一般的业务系统客户端与用户交互的时候都会使用下拉框组件,对于某些比较固定的值的下拉组件的数据来源一般都是比较固定的文本。

实现方案

有的人使用枚举或Constants实现,这种情况下在量少的前提是没问题,而且一旦需要修改就避免修改源码;随系统不断演进,后期将无法维护,甚至命名困难。

所以通常把字典放在数据库,维护变更就简单了,达到在不修改代码情况下也能修改配置。对于某些固定的数据字典(例如,星期,月份等)还就不允许修改。

但放在数据库又会造成频繁访问数据库,这也不是我们期望的,通常就是加缓 存,降低访问数据库的频率。

设计字典表

通常分成两张表来实现,一个是字典类型,一个是字典

  • 字典类型表: SYS_DICT_TYPE
字段名 类型 作用 备注
code varchar 编码 主键
name varchar 类型 展示用
  • 字典表 : SYS_DICT

    字段名 类型 作用 备注
    code varchar 编码 主键
    type_code varchar 类型code 外键
    name varchar 字典名 展示用
    value varchar 字典值 使用值
    fixed int 是否是固定的 default 0不固定,固定的话用1

以上是字典表的关键列和结构设计,根据不同系统不同业务自定其他列。

FAQ

字典类型应该不可编辑,因为字典类型通常会和具体代码实现紧密耦合,如果非要进行编辑话需要考虑到对代码的影响以及如何保证修改之后系统正常工作
字典分可编辑与不可编辑,所以在提供字典管理的时候需要注意fixed字段,针对固定的字典不提供编辑功能
字典与系统参数不要混为一谈,字典通常用于一类的数据,一组具有相同含义的数值(例如,供客户端下拉选择的枚举);而系统参数是针对某种配置或者某种系统常量的存在。

关于缓存

有人认为缓存增加维护成本,一旦使用缓存,对于编辑的数据得立马刷新缓存,不然将会与预期不符,并且对于访问不频繁量少的数据还达不到使用缓存的级别;有人认为缓存提高效率,减少数据访问。

不同场景使用缓存的条件不同,对于高频的数据或者对响应时间要求严格的系统可以增加缓存,但是带来的就是数据改动的同时需要及时更新缓存信息;对于对响应时间、业务要求较高的系统可以不用缓存,保证业务的正确性。
所以,具体情况具体分析,选择适合的。

文章来源: javaedge.blog.csdn.net,作者:JavaEdge.,版权归原作者所有,如需转载,请联系作者。

原文链接:javaedge.blog.csdn.net/article/details/113863115

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。