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

用元数据容器

我见过预留字段的设计，但一直没想明白有什么必要？预留字段肯定应对的不会是新增的控制信息（比如状态之类的控制字段）。那如果以后有新增信息，我再加上不行么？我一直以为，这种（预留字段的）设计是过去PowerBuilder开发时代遗留下来的，现在已经不必要了。借地盘正好问一下这种理解对不对。

第二种方法干脆把第一范式都给颠覆了。如果那样的话，我都不知道还用关系数据库干啥？
用key-value的方式倒是适应灵活性需求的通用办法。

你太搞了吧。。。表模型经常变化，咋设计的

经常变化内容就该用纵表。

偶们电信行业的业务描述那么复杂，也不会经常变化，再说模型一动是需要层层审批的，天天改谁受得了，10000多张表这么改早就死了

要抽象，看SAP多牛逼

现在在做行业软件的项目中，这情改动的情况是非常的普遍。
现在的客户信息部门即要求使用方案一，即预留字段。将来这引起字段的含意非常的模糊难懂。

但是个人不大赞同使用这种方法。同意pf_miles的观点，不为未来而设计。
能做的则是，收紧数据库改动的权限，控制好改动的的评审。

       大多数好的设计设计源于对业务的全面把握。对业务的不熟悉，肯定不会产出具有前瞻性的设计，因此就会出现库表结构的不停变化。多数情况，客户的核心业务不会经常剧烈变化，据我所知的电信，电力，人财物都已经有一些国际的业务标准模型。
当然，楼主的情况也可能是因为楼主已经达到领域知识的最前沿，而且该领域目前核心业务正处于激烈变化之中。

预留字段最省事,改起来最快;
我们一般都是这样做;每种类型预留10个;
另外一种,我们也采用就是设计一张关联表,
假设有A,B;两张独立表;设计一张C将他们关联起来;
A,B存放各自信息;C表只存放关联关系.
不过个人意见,如果时间比较充足,还是重新设计表,可能这样改动量比较大

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

预留字段太恶心了， 不推荐用预留字段。还需要整个文档描述一下哪个字段究竟是什么含义。
还是好好考虑设计吧， 既然不是做产品的， 应对敏捷变化是必然的。

正则的效率不高,有的数据库支持也不够好. 并且各自的正则写法可能不一样。

http://ihavegotyou.iteye.com/blog/560053

如果使用hibernate，加几个字段还是很快的。查询不用*，基本上改动也很小。
如果使用的是jdbc查询，所以的sql语句最好放在一个文件中