又要加字段？
现在一些新的概念层出不穷，什么微服务，云计算，虚拟化都不再是什么热词了，现在又流行Service Mesh，AI等等；今天我们不谈这些高大上的概念，我们聊些接地气的，聊些我们在开发中经常遇到的 checkbox,toggle啊之类的，一定认你有所收获。
问题描述
上面这两个图是我们在开发中经常遇到的，这里我们谈谈做为后端你是如何设计它他们的存储的呢？
第一张图是微信的权限设置，你是用三个字段来存储用户的设置吗？如果后续再新增几个配置呢？
第二张图是用户设置备份的数据类型，你是用四个字段来存储用户的设置吗？如果后续再新增几个配置呢？
OK,大家可能看出我表达的意义了，如果用多个字段分别来存储用户的配置的话，可扩展性不好，每新增一个配置项就城要新增一个字段。
解决办法
那要怎么处理呢？这里提供两种思路供大家参考：
把配置打散，用key-value的形式
什么意思？就是我们需要一张配置表，暂且叫他config表吧，它只有3个字段,id,key,value。如下图所示
| id | key | value |
|---|---|---|
| 1 | backup_sms | true |
| 2 | backup_email | true |
| 3 | backup_wechat | true |
| 4 | backup_call_log | false |
| 5 | need_verify | true |
| 6 | recommand | true |
| 7 | notify | true |
这样设置以后如果新增一个配置项，我们只需要插入一条记录即可。但是这样也有问题，就是所有配置项放在一张表里面不清晰，就算按功能划分成多张表，也有维护多张表的成本。所以下面这个方法了解一下？
二进制了解一下？
二进制跟我们这里的设计有什么关系？不急我们慢慢说。
我们知道二进制有很多的0,1组成，在每一个位置上面，不是0就是1。所以这是重点，我们可以把每一个位置做为一个配置项，记录用户是否打开了某个开关。第一张图有三个选项，并且都是打开状态，那我们就可以用二进制的111来表示用户的配置。
第二张图有四个选项，假设最后一个是关闭的，我们可以用1110来表示用户的配置。
这样我们只用两个整形的字段就可以表示用户的配置了，以后如果新增配置项的话，我们只需要新增一位0或1来表示就可以了。
当然二进制的这种方式也有弊端，就是只能表示开关的配置，在实际使用中需要注意。
灵感来源
java.lang.reflect.Modifier