如何定义数据表的扩展字段
因为产品升级或者产品项目适配等一些原因, 我们的关系型数据库的数据字段需要进行扩展; 比如我们原有一张user表, 其中有id, username, password字段, 现在我们需要这个user的age, male, address属性, 我们如何在原有的表基础上实现扩展呢?
我们通常使用如下几种方法来实现数据扩展: 动态添加字段、JSON格式储存、预留字段、属性字段行存储
(1), 动态添加属性字段
意思是，在需要添加一个属性时。先在数据库的表里添加一个字段。
比如说要给user有age的属性，就给user表添加age字段。那么要用这个字段时，还要改相应的java程序。显然这种方式不利于灵活扩展，而且在一张大表添加一个字段需要较长时间，这也不适合7*24的服务。
- 优点：符合数据表设计的习惯，实际使用中与原有字段基本无差别
- 缺点：每增加一个属性就要改相应的Java程序，不利于灵活扩展
(2), JSON格式储存
就是说把需扩展的一组字段都到到一个字段里，各个字段用JSON的方式组成一个大的字符串。
比如上边的user表可以这样设计：
| 字段 | 类型 | 备注 | 数据实例 |
|---|---|---|---|
| id | int(10) | ID | 1239512 |
| username | varchar(20) | 用户名 | zhangsan |
| password | varchar(20) | 密码 | qwerty |
| version | int(10) | 版本(扩展字段的版本) | 3 |
| extended_filed | varchar(200) | 扩展字段 | {'age': '18', 'male': 'F', 'address': 'hefei'} |
- 优点：insert/update/delete都可以比较方便的操作；不用频繁改动表结构和过多的Java代码
- 缺点：扩展字段不支持索引；key名大量冗余；如果要根据扩展字段进行查询不方便，也不高效，需要遍历所以数据；
(3), 预留字段
就是先给表定义几个扩展字段，还是以user表为例。
给user表定义几个预留字段，这样任何数据类型都可以解析为字符串，把编码后的数据存进去就行了。
| 字段 | 类型 | 备注 | 数据实例 |
|---|---|---|---|
| id | int(10) | ID | 1239512 |
| username | varchar(20) | 用户名 | zhangsan |
| password | varchar(20) | 密码 | qwerty |
| extended_filed1 | varchar(50) | 预留扩展字段1 | 18 |
| extended_filed2 | varchar(50) | 预留扩展字段2 | F |
| extended_filed3 | varchar(50) | 预留扩展字段3 | hefei |
- 优点：可以正常的select/insert/delete/update；一些复杂的查询也可以实现
- 缺点：太少可能起不到作用，太多也不行，影响性能；扩展字段是公用的，不能根据字段名顾名思义，得在启用时维护对应关系，使用时查找对应关系；扩展字段的数量无法精确定义。
(4), 属性字段行存储
顾名思义，此方法需要新建一个属性字段表，在这个表里维护扩展字段的字段名和字段值
如user表的扩展字段表
| 字段 | 类型 | 备注 | 数据实例 |
|---|---|---|---|
| id | int(10) | ID | 13214213 |
| user_id | int(10) | user表的ID属性 | 1239512 |
| filed_name | varchar(20) | 扩展字段名 | age |
| filed_value | varchar(20) | 扩展字段值 | 18 |
- 优点：字段名能够顾名思义，字段也可以动态扩展
- 缺点：key名称大量冗余，所以key命名尽量短，可使用编码；select/insert/delete/update时需要操作两张表，操作稍微复杂
(5), 扩展字段配置表和扩展字段值表
多个表的扩展字段属性和扩展字段值，配置储存在一张表中，值分开储存在多张表中
扩展字段表：
扩展字段值表：
- 优点：优点：只需维护配置表即可，减少代码维护量
- 缺点：操作比较复杂