Sql Server2000一个表几百个列，操作效率如何

[dingyin]

基本表大约100个列，组合起来的查询统计表会有300多列，这么多的列效率如何心中无数，也没找到这方面的资料，但是记得以前曾看到过文章，说是一个表列数大约20个以内，操作效率最高，太多了效率就成问题了。

数据库是Sql Server2000,请各位发表意见，有实际经验或数据资料最好。

[dingyin]

不过每个表的行数不会很多，至多不过1000行左右。

[pengdali]

Sql Server2000每个基础数据表的列数最多 1,024个列 每个SELECT 语句的列数最多为 4,096

300多列应该没有影响的！速度取决于你的io，而不是cpu

[ckp]

如果查询条件不复杂,则取决于硬盘存取的速度.

[helphelpmeme]

我做过一个表有200多个列的速度很慢啊。

[liuyun2003]

什么样的数据需要那么多列啊?

[zosky]

最好纵向分割吧？

[f30]

这样的表设计就不合理吧

[skyzj]

如此多的列，我想不出是什么样的数据，可否透露一下，让我们开开眼，
另外我也有些怀疑表的合理性

[datura_x]

把经常组合在一起查询的字段分在一组，多分几个表，并分布在不同分区的文件组里，用视图把它们合起来。我觉得这样能好一些。

[start1127]

这样不是很好，但是考虑到数据量不大，可能也看不出有多少影响。不过确实是io负载较高，你想啊，一页8k能保存几条纪录啊，查询时候就等着频繁翻页吧：）

[caiyunxia]

可以

[goneaway]

纵向分割，或者考虑设计的问题分析一下这样的实体是否可以再细分成更小的实体。

[dingyin]

各位说的有道理，查询统计表所以有三四百列，正是有结构差不多的几个表组合而成的，所以考虑单独建表，一是速度问题，二是易于操作的问题，因为一个查询统计表就是一个报表，用一个单独的表对应，比较好处理。
用视图的话，如果查询速度和单表相近，那可能用视图更方便点。

至于基本表，不是不可以纵向分割，问题是分割后的东西基本不是独立使用的，查询的时候，都要组合起来。

为什么有这么多列，想象一个二维表格，横向二三十行，纵向五六列，不分割，把二维变成一维，一乘就有一百列了，再加上年，月，累计等的统计，再一组合，就有三四百列了。

[datura_x]

原来是做统计表，如果统计表的列太多，而且经常被改，我一般是这样做的：
将所有列平均分为若干组，每组标号，设计的TABLE有一个标号列。这样，统计表多宽都不用动结构了。只是取出来后在客户端稍做处理就OK了。

举个例子：TABLEA，字段：（表号、日期、单位（表行名）、行标、列1、列2。。。。。列15）
假如一个统计表有40列，那么第1-15列的行标为1，16-30列的行标为2，31-40列行标为3；
每条统计记录分布在3行里。
用表号的字段，可以一张TABLE管理多个统计表。我这人很懒，这么着，不管什么统计表，报表代码基本完全一样。
至于查询时，多加个标号字段的判断就行了。
OK？

[datura_x]

补充说明：统计表的第16列，对应列1，行标=2，32列对应列2，行标=3