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

为什么需要字典表？

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

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

实现方案

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

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

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

设计字典表

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

• 字典类型表: SYS_DICT_TYPE

• 字典表 : SYS_DICT

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

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

FAQ

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

关于缓存

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

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