应对表扩展的一列

需求缘起

产品第一版：用户有用户名、密码、昵称等三个属性,对应表设计：

user(uid, name, passwd, nick)

第二版，产品经理增加了年龄，性别两个属性,表结构可能要变成：

user(uid, name, passwd, nick, age, sex)

假设数据量和并发量比较大，怎么变？

（1）alter table add column？不太可行，锁表时间长

（2）新表+触发器？如果数据量太大，新表不一定装得下，何况触发器对数据库性能的影响比较高

（3）让dba来搞？新表，迁移数据，一致性校验，rename？dba真苦逼

 

方案一：版本号+通用列

以上面的用户表为例，假设只有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会更适合

 

方案二：通过扩展行的方式来扩展属性

以上面的用户表为例，可以设计为

user(uid, key, value)

初期有name, passwd, nick三个属性，那么数据为：

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

优点：

（1）可以随时动态扩展属性

（2）新旧两种数据可以同时存在

（3）迁移数据方便，写个小程序可以将新增的属性加上

（4）各个属性上都可以查询

不足：

（1）key值有大量冗余，建议key短一些

（2）本来一条记录很多属性，会变成多条记录，行数会增加很多

 

总结

可以通过“version+ext”或者“key+value”的方式来满足产品新增列的需求，希望没有浪费你这一分钟，有收获就好。