基础数据的思考

    相信大家在平常开发过程中，经常会遇到各种各样的基础数据。例如，订单的状态，各种分类等。例如：用户类型有三种类型：普通用户，高级用户，管理员。一般情况下大家，可能大家都不会直接将值存入数据库。可能存入1、2、3，然后在前台显示的时候做下转换。不知道大家有没有想过这样做到底有什么好处没有。我能想到的有2点：第一点：节省数据库空间。第二点。假如某一天普通用户不叫普通用户了。改叫一般用户。可以不用修改数据库里面的值，只用修改转换方法。
    但是我在最近做的过程，一直很纠结要不要这么做。针对上面的2点理由，我觉得第一，节省的数据库空间其实真的可以忽略不计。第二点：一般来说，当项目真正上线之后。这些基础数据90%不会发生变动，或者变动频率很小。。。反而，因为要做这种转换，有时候会增加我们的开发量。大家可能觉得这也花不了多少功夫，但是假如将用户类型换成户口所在地呢？
     所以，我想问下大家，针对类似这种基础数据，我们应该依据什么样的原则来判断是否要进行这种转换处理？

介绍给你一个概念：MDM（主数据管理）。
比如你举的例子， 普通用户，高级用户，管理员分别对应1，2，3
如果有一天，普通用户需要更改名字，变为一般用户。如果采用了MDM，你只需要更改一条数据即可。而如果你的所有数据存的都是普通用户，那么需要涉及的数据就很多了。
其实，更主要的原因是，采用MDM, 与外部系统交互时，对应关系很容易取到。你传出去一个1，其他系统如果想知道具体的含义，只需要一个简单的映射即可。
不知道明白没有？

主数据管理是针对公司的业务数据的管理。。我这说的是指我们系统中定义的一些基础数据。是恒定。就像我举得例子中。。我所关心的不是用户数据的管理。。我想讨论的是类似用户分类这些基础数据的管理。。

这种问题只能根据具体的项目环境来看，不过在大型的系统中，对数据库空间的节约还是非常可观的~

明白楼主的想要表达的意思
通常这种状态基础数据、或者是一些常量基础数据。可以用lookup表来存储。所有的常量数据只用维护一个表就可以。

哪里查到的MDM只针对公司的业务数据的管理？求教

推荐还是使用 123 这种.因为数字类型匹配起来是比 varchar 快.内存磁盘占用空间都少.
但有 3 种方式,

1. 表结构使用数据库 enum 类型
2. Java 里的 enum.
3. 字典表
对应的看法:
1. 没这样做过,因为是业务逻辑,没想延伸到数据库(或许这个理由不成立,但确实没这么做过.仿佛就是没这种习惯,而且Mysql 支持 Oracle 不支持.)
2. 这个无论用编码或者实现都是比较方便的,不好的地方是两个子模块要用一个数据库的时候,要在两个地方硬编码,也不能再修改名字.
3. 字典表,即上文说的 lookup表.一般这个表要做缓存.或许编码要稍麻烦点.