在软件开发的过程，经常有一些类型的字段信息：性别、学历、职级、车辆类别、公司类型、结算类型等。这些字段有2个特征：1是字段可选的类型是有限，2是字段可能会变化，我们把这种字段描述为字段字段。 本篇文章重点总结系统字典模块的设计，根据我的工作经验，我对字典模块的设计认知包含如下几个阶段：
一、硬编码到页面
这个阶段，一般是把可以枚举的option写在html，或者通过后台模板硬编码到html中。这种方式的实现优点在于实现简单，也没有依靠数据库。但是缺点也是很明显，如果这些字段发生了变化，需要去改代码，还需要重新发布代码。
二、在数据建表，以附表的形式
例如在一个订单表中，有一个结算字段，当然结算的类型是有限，我们可以建立一个结算类型表。这样订单表只存结算的字段id，这样也能做到动态添加结算类型。这样做缺点在于，加了一个字段字段就加一个表，那么有几百上千个字段就需要多太多的表。而且在获取数据的时候，需要去连接查询拿到数据，其实也会影响性能
三、统一建字典表去管理所有的字典
目前我们公司采用的就是这种方式去统一管理所有的字典，我们使用2个表去实现这样一个模块。一个是字典类型表，一个是字典选项表。一个字典类型，对应多个字典选项表。字典表有如下字段：
| 字段名称 | 字段类型 | 字段含义 |
| id | int | 主键 |
| dict_type | string | 字典的英文表示,如性别可以描述为gender |
| dict_name | string | 字典名称，例如性别 |
| tags | string | 标签，可以有多个，用逗号拼接 |
| common字段 | 一些通用管理字段，如更新时间，更新人，创建人等 | |
这个表需要注意的是，要留tags字段作为扩展，经常有的ERP系统之中，字典可能有几千个，需要一些标识去分割。例如可以将字典的类型分为财务、综管、生产等，这样方便显示。
也可以将一些权限的表示放入其中，例如tags包含role:1表示role的id为1的才能去修改字典等。
字典选项表如下：
| 字段名称 | 字段类型 | 字段含义 | |
| id | |||
| dict_id | 关联的是dict_type的id | 字典类型id | |
| dict_value_id | 字典选项的option的key，也可以不要次字段，这样option的key就是id | ||
| dict_value |
|
||
| code | 字典选型的编码 | ||
| sort等通用字段 |
需要注意的是dict_value_id可以不需要，这样dict_value_id可以和id一致。采用这样的实现方式，可以统一管理所有的字典，但是会需要一些基础的公用代码去解决使用的问题。
1、字典选项的呈现的问题
有这样一个场景，有一个学生表，有一个性别字段。我们在字典表里加入一个gender的字典，添加2个option，1:男，2:女。那么性别字段中存的是1或者2。
首先在学生数据录入的时候，页面层必须知道性别这个字段是字典类型，然后可以通过这个字典类型的dict_type去拉去dict_value，这样就能呈现。同样在学生表数据呈现的时候，后端可以统一替换字典项的id为name，也可以直接返回给前端，让前端统一替换所有的字段项的值。当然在具体实现的过程中，可以使用缓存去存储所有的字典的数据，也可以通过一些约定的形式，采用动态实现的方式，在框架层替换option的值。例如所有的字典字段，名称都必须是_dict_type。
2、字典选项被删除的问题
例如学生表中的option的男被删除了，那么学生表中的性别为1的数据就会出现问题。目前我们采用的解决方式是dict_value采用逻辑删除的方式，这样数据删除了也能正常显示。不过具体需要根据需求去解决这个问题，例如不存在的option设置为一些异常标识。