现有表1：
年度 指标 指标值
2000-01 A 100
2000-01 B 200
2000-01 C 300
...
2000-02 A 150
2000-02 B 250
2000-02 C 350
... 转换成表2：
年月 A B C ...
2000-01 100 200 300 ...
2000-02 150 250 350 ...
.......表2的列是根据指标数目的多少动态创建的，
显然，如果有100个指标，表2就有1+100列，但数据行则是表1的1/100，
现在不是讨论如何转换的问题，而是想问在数据量比较大的情况下：
1、若要查询某一年月某一指标的值，用哪张表效率更高？
2、表2的列数(即指标数)多少比较合适或者可以承受？
3、当表2列数不断增多(行数不变)时，是否会很明显的影响查询性能？
年度 指标 指标值
2000-01 A 100
2000-01 B 200
2000-01 C 300
...
2000-02 A 150
2000-02 B 250
2000-02 C 350
... 转换成表2：
年月 A B C ...
2000-01 100 200 300 ...
2000-02 150 250 350 ...
.......表2的列是根据指标数目的多少动态创建的，
显然，如果有100个指标，表2就有1+100列，但数据行则是表1的1/100，
现在不是讨论如何转换的问题，而是想问在数据量比较大的情况下：
1、若要查询某一年月某一指标的值，用哪张表效率更高？
2、表2的列数(即指标数)多少比较合适或者可以承受？
3、当表2列数不断增多(行数不变)时，是否会很明显的影响查询性能？
不过大家帮忙的时候最好能有点理论支持，呵呵
第1问为什么是表1呢？如果指标数100，表1有100万行的话，表2才1万行呀，列数多对查询性能有这么大影响吗？
首先不管表2有多少列，你只察其中的一列时，再有索引的条件下oracle会直接所要的定位到rowid，
然后，直接找它的哪一列的值，表一也应该相同，但是记录要更多，因此2快。
我认为在实际应用中，1只是用于记录，2应该是根据1表生成，用于统计
2.ORACLE最大支持1000列，具体多少列合适，没测试过
3.只察一列应该没有影响，也没有测试过
所谓窄表就是你的表1
胖表就是你的表2
建窄表的效率更优。这是数据库优化里面的内容。具体的你可以在sqlplus 里面执行，看他们用的时间和执行路径就知道了。
如果单独来考虑，毫无疑问应该是如ynwpl(Brave&Heart) 所说窄表效率更优，我自己作了一下测试，不知道有没有参考价值。
以200个指标，1000个时间点为样本，
这样用表2存储仅1000行(201列的胖表)，而用表1存储有20万行(3列的窄表)；
表2索引PK(年度)，表1索引PK(年度，指标)。
以下为进行各种操作所花费的时间(仅供参考)
操作方式 表2 表1
循环方式插入所有数据 10.03 339.85
单个指标某时间点查询 0.15 0.15
单个指标某时间段查询 0.19 0.19
多个指标某时间点查询 0.16 0.19
多个指标某时间段查询 0.22 1.28
单个指标某时间段合计 0.16 0.16
某时间点多个指标合计 0.16 0.16根据以上数据，进行查询统计时两种方式几乎不分上下，
插入操作由于数据量的较大差异导致时间上的差异，
如果以插入1000行数据到不同列数的表来测试，
表2(201列)用时10.03秒
表2(101列)用时4.84秒
表1(3列)用时1.81秒