如何应对表结构经常变化？
我在网上看到有人讲到三种方法
第一种方法，预留字段
第二种方法，使用复杂字段，操作的性能也不错，但是复杂字段里面的内容查询比较困难
第三种使用 列表的方法。
大家有经验的请讲讲，我对第三种方法感兴趣，有没有相关的例子学习的？
[解决办法]
你应该研究为什么表结构经常变化？
而不是去应对这种表结构经常变化。
通常“表结构经常变化”的原因是没有按照一定的规范进行程序开发导致。
缺乏经验，缺乏系统分析、缺乏工程管理人员。
如果具备一个完善的开发步骤和体系，具备有经验的开发人员领队，同时
具备项目管理和系统分析人员，这种“表结构经常变化”的问题很少会出现，
甚至是不会出现。因为出现这种问题是计划不周的表现，计划不周表示经验
不足，是种能力不足的体现。
[解决办法]
有时候有新的要求时，加点列的情况是有滴啊。
经常的是设计的有问题。
[解决办法]
其实在一个正规的大型软件开发项目中，起码要经历这样几个步骤：
1、了解需求
2、分析需求并做出流程分析
3、反复挖掘需求讨论流程
4、出系统分析书
5、开发工具、技术的选型（包括接口定制以及数据库设计以及架构可实施方案等）
6、定制开发计划，制定到人、接口、时间段、任务、调试周期、意外周期和备选人员方案包括验收方法等
7、讨论并修改开发计划
8、开始实施计划
9、多次整体测试检验
曾经的经验，如果有一个项目是1年的时间，前期可能有1-两个月搞需求分析
之后有大半年搞系统技术选型和方案策划等等前期工作
最后只有两三个月按计划写码
中间不可能有什么“表结构经常变化”的问题，因为所做的事情全是按计划进行，不可能到写码
或是市场运作时才出现这类问题，因为这种问题应该在前期就考虑完，最多预留几个字段为了后期
市场运作时做意外准备。但通常都用不上。
[解决办法]
使用结构库，数据表使用结构库里的结构表自动生成，程序要能智能判断处理不定的字段。
[解决办法]
表结构不断变化，那就换个思路。
比如人员表：姓名，性别，年龄等
改成人员表：人员属性名称，人员属性值。
属性就可以任意增加了，姓名、性别都是属性。
然后建一个交叉表视图就可以了。
[解决办法]
一般来说, 正常的应用很少会遇到表结构经常变化的问题.
因为对应于数据库应用来说, 数据库表结构的定义还在代码之前, 属于房子的"地基"范畴.
所以这种变动属于很不合理的.
至于客户的要求, 这个也是可以理解的, 我也遇到过不少客户根本就不能把问题完整并且合乎逻辑得表达出来的情况.
这种情况下, 一般来说要作的并非无条件的以为迎合客户, 而是应该从你开发和技术的角度去引导客户尽可能得把问题描述清楚, 并且帮助他们归纳数据. 这样就能做到在开始代码之前尽量构建出一个最贴近用户实际需要的数据库来. 但是这也需要有一定的开发经验,并且还要做到沟通顺畅. 事实中连普通话都说得疙疙瘩瘩的技术人员我却见过不少.
因为客户一开始往往接触的是公司的销售人员, 你也知道, 销售基本上为了拿到合同是会大包大揽的. 而具体的技术和业务流程方面则需要有技术或开发人员的参与了. 如果做不到把开发中可能遇到的各种开销告知用户,并且详尽得了解问题实质的话, 那么接下来的开发很有可能偏题,从而导致后续的不顺畅.
还有一种就是要注意的地方, 程序代码要尽量灵活和有扩充性, 这就需要在写代码的时候尽量多考虑了.
比如说:
引用数据表的时候尽量不直接引用字段名, 而是使用字段编号
例子: 假设目前的表有3个字段: AA,BB,CC
你写成
Recordset.Field("AA").value
Recordset.Field("BB").value
Recordset.Field("CC").value
很差劲.
而写成:
For I=0 to RecordSet.Fields.count-1
RecordSet.Field(I).value
next
则要灵活得多.
诸如此类的技巧还有很多, 不一一道来了. 但是技巧再高明, 也是无法补全设计上的先天不足的.
[解决办法]
