如何应对表结构经常变化？

我比较不喜欢预留字段的方法，看到预留字段的字段名就感觉难受，也想不明白等到业务需要时才“临时”增加字段有什么不可以

agan??
我的看法是..数据库设计不为了“未来”而设计，所以我反对“预留字段”的方法；
依我个人的经验上讲，表结构做到3范式，并且任何字段都不带结构(只是一个意义单一的值而已)，总体来说这样的数据库设计是很好扩展的；
“很好扩展”基本上是指如果业务要新增概念，那么只需要通过添加字段或者添加新表完成扩展，而不是更改字段本身或者删除字段（有点“开闭原则”的意思，我觉得不管是对象设计还是数据库设计这点是部分共通的）
看得出来你已经对这些“很好扩展”的扩展进行抱怨了；
确实，如果业务变化很快，那么就算变化朝着正常方向发展（只增不删改），也不免会让人觉得烦；
我觉得这种烦恼很大部分是因为我们不仅在代码中维护了所有的业务概念，同时在关系型数据库表中也维护了一份业务概念——我们要具体到某个字段来存储，表结构实际上非常具体地展现了业务数据——这就导致业务一变，除了代码要变之外，数据库表结构也可能变；
这样我觉得有意思的事情就来了：你需要用数据库进行关系运算么？
数据库表非常具体地展现了所有的业务字段细节，为的是做关系运算，比如连接查询；
简单看了一下你提到的“复杂字段”和后面的“key-value”方案，如果这样的方案能满足你的业务需要，那么说明你的业务是不需要数据库做关系运算的，进而也不需要关系型数据库了...所以这里你不妨考虑一下对象数据库
就像bigTable一样，所有的东西都有一个identity取出来，以一个对象的形式，所有的业务逻辑就只存在于代码中