数据库-表扩展

架构

需求缘起

产品第一版：用户有用户名、密码、昵称等三个属性,对应表设计：
user(uid, name, passwd, nick)
第二版，产品经理增加了年龄，性别两个属性,表结构可能要变成：
user(uid, name, passwd, nick, age, sex)

解决方案

（1）alter table add column

不太可行，锁表时间长。大数据高并发情况下，一定不可行

（2）通过增加表的方式扩展，通过外键join来查询

大数据高并发情况下，join性能较差，一定不可行

（3）通过增加表的方式扩展，通过视图来对外

一定不可行。大数据高并发情况下，互联网不怎么使用视图，至少58禁止使用视图

（4）提前预留一些reserved字段

这个是可以的。但如果预留过多，会造成空间浪费，预留过少，不一定达得到扩展效果。

（5）通过增加表的方式扩展列，上游通过service来屏蔽底层的细节

这个也是可以的。Jeff同学提到的UserExt(uid, newCol1, newCol2)就是这样的方案（但join连表和视图是不行的）

（6）版本号+通用列

以上面的用户表为例，假设只有uid和name上有查询需求，表可以设计为
user(uid, name, version, ext)
1. uid和name有查询需求，必须设计为单独的列并建立索引
2. version是版本号字段，它对ext进行了版本解释
3. ext采用可扩展的字符串协议载体，承载被查询的属性

例如，最开始上线的时候，版本为0，此时只有passwd和nick两个属性，那么数据为：

当产品经理需要扩展属性时，新数据将版本变为1，此时新增了age和sex两个数据，数据变为：

优点：
（1）可以随时动态扩展属性
（2）新旧两种数据可以同时存在
（3）迁移数据方便，写个小程序将旧版本ext的改为新版本的ext，并修改version
不足：
（1）ext里的字段无法建立索引
（2）ext里的key值有大量冗余，建议key短一些
改进：
（1）如果ext里的属性有索引需求，可能Nosql的如MongoDB会更适合

（7）通过扩展行的方式来扩展属性

以上面的用户表为例，可以设计为
user(uid, key, value)
初期有name, passwd, nick三个属性，那么数据为：

未来扩展了age和sex两个属性，数据变为：

优点：
（1）可以随时动态扩展属性
（2）新旧两种数据可以同时存在
（3）迁移数据方便，写个小程序可以将新增的属性加上
（4）各个属性上都可以查询
不足：
（1）key值有大量冗余，建议key短一些
（2）本来一条记录很多属性，会变成多条记录，行数会增加很多