关于电信报表系统设计

现在所在的公司是做电信业务:
公司有一套报表系统,其设计思路是这样的
使用客户:一个省的电信营业厅
技术:servlet + javabean
设计思路:
1)将报表系统用到的比较固定的数据,比如系统参数,目录树等的数据放入系统初始后的一个静态数组里面
2)系统报表用唯一的reportID做为标识将一个报表数据拆分为表头信息,报表描述信息,报表列描述信息,报表数据(唯一变化的数据),报表尾部信息分别存于不同的数据表中,当点击查询这个报表时,将不变的数据取出放入静态数组中,以便复用.让后组织sql语句查询并展现数据
存在的缺点:
1)报表页面美工较差
2)系统整个结构不是很清晰
3)大量使用了静态数据,静态方法
4)当达到300连接时整个系统相应很慢
以前系统的优点:
1)固定的数据如系统参数可以存于静态数据容器中,避免了频繁的数据库访问


重构计划:
采用MVC(Struts(或其它的MVC结构)三层结构,前台展现用jsp+javascript,中间层用sessionbean,后台数据采用dao+ejb/dao+javabean两种模式,对于报表数据采用dao+javabean,其他一次性加载的数据用dao+ejb方式

采用MVC结构后这个系统的框架得到解决,页面表现可以做的更好
后台采用dao+ejb/dao+javabean的基于以下考虑,对于以前系统简单的数据查询完全用dao+ejb代替,不在使用静态数据存储,对于复杂的数据库操作使用javabean封装数据库操作,对数据库操作进行优化
对于报表的展现首先将数据从数据库取出,对需要交叉,分组,反转的报表在客户户端处理,用jsp展现.

但现在的担心是,整个省的营业厅进行并发操作的情况下,系统相应是不是会变的很慢?

跟robbin相反，我纳闷的是看不出chief365的问题。重构中提到用MVC模式来构建新的系统，然后呢？

我对于robbin先生是比较欣赏,但对于论坛的管理,我想我是否可以说几句话,
首先并不是每个人都是高手,因此在提问问题的时候有很多人都会采用请教的方式,如果有人比较热心可以,回答这个问题,但没有必要动不动,我们这里不做免费咨询的回答.我想论坛就是给人一个交流的地方,大家可以踊跃的发言,这样才会有一个好的发展.并不是每个人都是高手,这个论坛也不是一个专供高手展示自己水平的地方吧.对于此论坛,我看robbin大有一手遮天之感觉,整个论坛的交流具有很大的倾向
对于此类事件的发生已经是很多了,我想我写出这些话一定会遭到很多人的口水,甚至....但我还是要说这些话
声明:本人能力有限,很多观点还是同意本论坛的发贴必读的
但看到一句话感觉很不好

不想删贴的.怎么....

尊重别人,也是尊重自己.

为什么反对你的帖子

话题既然转到论坛管理，那么就移一下贴。

你自己看看你第一贴究竟像不像一个商业项目计划书？你原贴本来还有一句“欢迎大家踊跃发言”。大家踊跃不踊跃发言不取决于你欢迎不欢迎，而取决于你提的问题是否值得大家去思考。

3月上海聚会最后演讲的joe是HP公司的技术顾问，他也经常在论坛给别人长篇大论的解决问题，但是解决私人问题和给公司做解决方案书两回事。解决私人问题是凭个人喜好的，是免费的，给公司写解决方案是商业行为，要收费的。

我也经常请教他问题，至少在他熟悉的那个领域，我也是一个新手，但是我不会去过分的要求，也刻意回避这种有让他给我做免费技术咨询的问题。作为一个具备专业素质的从业人员，我认为应该有这种意识。我和joe认识有3年多了，是很好的朋友了，但是一旦涉及到要求他提供解决方案的时候，他就会说no。所以你提出来这种问题，我也会说no。上次我要写一个备份方案书，就问joe有没有这方面的，可以参考一下吗？他说有，但是no，不能给你，然后他推荐我一些网站，让我自己去找。我认为他拒绝我拒绝的很有道理，我不会因此而不高兴。

除非你自己提出问题，并且给出来你自己的解决方案，供大家讨论和借鉴的时候，我认为才是允许的。就好像我如果要向joe要一个备份解决方案，他手里当然有，但是他会说不能给你，那么如果我做好了一个解决方案，请他提提建议，他才不会拒绝。

我制订论坛发贴的规则，不是站在一个很高的位置在限制新手的角度来制订的，我制订规则的时候，我心里就是想着我是一个新手，我向joe，向jebtang这些在Infrastructure方面的高手请教的时候，我应该持一个什么样的正确的态度，应该如何更好提出问题，应该如何避免要他们免费的帮我做本来他们在公司做的工作之内的那些事情。

高手帮人家解决问题，他们花的时间和精力是最稀缺的资源，作为一个提问者应该具备的基本素质就是要尽量做到不过分要求，把人家花在你问题上的时间和精力成本降到最低。做不到这一点，那么就不要抱怨被删贴了。

你最后引用的这句话也是我要强调的：

首先声明的是:我没有让任何人提供什么解决方案的意思
你是看到的,我也提出了自己的观点,当然,也许你并不认为这是观点.你想让我提供什么样的观点呢.
其实,我注册到这个网站很长时间,但我很少在这儿发贴.
郁闷!!!

既然要解决的是高并发的性能问题，那么得先找到性能瓶颈吧。比如说原先300并发之后速度慢，那么究竟原因何在？

再仔细看了一下帖子，觉得我自己还是太鲁莽了一些，向td_chief365道歉！我承认我上面批评是错误的，请原谅。

一般业界做报表都是遵循 模板 －》 填数据 －》显示的方式的。
不知道为什么楼主不采用主流方式？

首先我也像robbin道歉,有些话我也说的有点过分,并且当时我的贴子写的过于潦草,的确有让人提供解决方案之嫌, 不过我真是用意可不是这样啊
谢谢robbin先生的指教,
我的想法也是这样的,
对于原来的旧系统,我感觉瓶颈的地方应该是查询报表系统数据库语句没有优化的原因,我看了服务器的配置,对于数据库连接池也没有很好的处理.
我现在正用optimizate进行测试,

我们以前的系统是很久以前开发的,当时开发系统的人已经离开公司了,但整个系统整体上也是这种模板填数据模式,但整个架构显的很乱,我们重构的目的
1)重新设定系统的架构,以便系统维护
2)解决系统瓶颈问题
其实我们现在的想法是取出报表数据----分组/交叉...----模板显示数据这种思路来的
对于报表的二次操作比如反转,是在客户端用处理还是在服务端处理还拿不定主意.

对于复杂的月报、季报一些不经常使用的报表，可以考虑用存储过程生成数据，放到一张表中，显示的时候只是查询数据就行了。