数据库可扩展设计方案

数据库表的字段扩展方案

传统方案
一. 预留字段
预留字段就是在数据库表设计之初，预先留一定的字段用于后续的业务扩充，例如
在设计之初用户表为user(uid,name,col1,col2,col3....)。当需要扩展字段时可以直接试用预留字段。
优点
1. 业务扩展后新增不需要锁表
2. 避免alter table user add命令造成锁表，当表中数据很多时这个语句会造成长时间的锁表。
缺点：
1. 预留空字段浪费空间（虽然可以忽略不记）。
2. 预留字段可读性往往不强，虽然可以用过alter table user rename column语句去改写列名，但一样会造成锁表，影响tps。
3. 当预留字段用完或者数据类型和要新增字段不符的场景下，还是需要用alter table user add命令去添加字段。

二. 新建表做join
大数据高并发下join带来的性能问题会严重影响tps，而且一些优化器不太好的数据库遇到join容易变的很慢。做view等同于做join

增加数据冗余反范式化的方案
一. 使用版本号和通用字段
即在设计之初用户表为user(uid,name,version,content)
系统刚上线（v0版本）时数据为
1 张三 0 {passwd:123}
2 李四 0 {passwd:456}
v1版本增加了age,sex字段后数据为
1 张三 0 {passwd:123}
2 李四 0 {passwd:456}
3 王五 1 {passwd:789,sex:1,age:10}
旧版本数据可以通过写个运维程序来更新，这样增加字段就不需要锁表了。
优点
新增字段无需锁表，数据可以区分版本，旧数据升级简单
缺点
1. content字段内的数据无法做索引，不过有些数据库支持json检索
2. content字段内的真实字段有大量冗余，1000条数据就要存1000个冗余的"passwd"、"sex"和"age"

二、通过行来进行数据扩展
用户表的结构变成了这样 user(uid,key,value)
系统上线时数据是
1 name 张三
1 passwd 123
2 name 李四
2 passwd 123
系统改版后数据变成
1 name 张三
1 passwd 123
2 name 李四
2 passwd 123
3 name 王五
3 passwd 123
3 sex 1
3 age 18

优点：
1. 动态扩展不需要锁表
2. 可以针对每一个属性创建索引（实际上对uid建索引就够了）
3. 旧数据可以写个运维程序来更新

缺点
1. 数据库记录数很多，每增加一个属性就要线性增长
2. 大量的冗余数据（key字段）

转载于:https://www.cnblogs.com/aegis1019/p/9180496.html