我们利用一台服务器跑大型数据库，上面存储了统计局各个科室的历年数据，然后在每个统计人员的办公电脑上安装统计程序，统计人员就在自己的电脑上进行操作：需要统计时先选择和录入统计的条件，点击一个按钮，程序就把所有满足条件的记录从数据库中查询出来，缓存在本地进行计算直到得出最终结果。这期间，用户能做的事情只有两个，要么取消操作；要么一直等待，因为他们那些赛扬配置的办公用机早已CPU满负荷，内存耗尽了。

现在想来，当时仓促间设计的方案实在太原始，明显存在以下的问题：

1.       大型数据库系统除了简单的存储数据外，其自身强大的数据分析和报表功能一点没     有用上，着实是一种浪费。

2.       用户所用电脑即客户端承担了复杂而又庞大的数据计算任务，本身负载很重，当多   个用户同时操作时必然也给数据库服务器和整个网络带来很大的负载。

3.       客户端既是业务逻辑处理端也是数据浏览端，功能过于集中，当不同用户处理数据的方式和数量存在较大差别时，很难平衡负载，提高效率。

尽管后来使用Web Service技术，专门增加了一台服务器承担数据统计的任务，并在网络上向客户端发送统计结果，但是这样做仍然存在很大弊端。首先，该数据统计服务器在多用户同时操作的时候仍然负载很大；其次，生成的若干统计数据集通过Web服务发送给客户端往往实现复杂且很耗时，更何况还要与数据库服务器进行互操作包括数据的查询和存储，效率反而下降；最后，增加一台服务器的成本也很高昂。此时，整个解决方案的物理结构如下：

那么，原来的方案只能全盘否定吗？那倒未必，由于该统计系统可以应用于不同的数据库系统，如果过多依赖于数据库本身提供的功能，反而限制了系统的通用性，毕竟每种数据库平台都有各自的特点。从某种程度而言，原始的方案也有其优越的地方。同时，虽然直接使用低配置的客户机进行汇总操作使得客户机负担较大，但多个用户同时操作时对数据库服务器的压力就小很多，实际上将计算的任务分散开来，且省去了专门用于计算的服务器而节约了成本。

鉴于此不禁让人想到分布式计算的原理，既然各个科室的统计人员分别统计自己的专业数据，一般互不相干，最后各个科室汇总的结果再由综合科统一处理而生成完整的统计业务数据，那么就可以给每个科室分配一台P4级别，内存稍大的计算机作用应用服务器，由该机完成本科室的所有统计业务。统计人员则可以在自己的电脑上作其它的事情，比如录入数据，浏览已经存入数据库的数据等等，从而提高了工作效率。而且，这样P4级别配置的价格已经很便宜，但功能强大许多，统计局的科室并不多，所以即使都配上也远远比买一台专业服务器的性价比高。此时的解决方案就如下图所示：

注意，客户机在这个时候也不必直接访问数据库服务器，而是通过本科室这台专门的应用程序服务器获取数据，并且仅要完成数据查询展现以及数据手工录入等简单的功能，减轻了自身的负担。如果统计人员没有意见，甚至可以用较为古老的配置。另外，由于每个科室只有几个统计人员，只有个别人才有权限在应用服务器上进行汇总操作，那么不但减轻了该应用服务器的负载也提高了数据的安全性和可维护性。

然而事情还远没有结束，这些应用服务器统计出来的数据结果该如何存放呢，怎样才能方便用户的查询呢？这些数据中有的仅仅是半成品，还要交给别的部门继续汇总，有的则已经符合存储的要求应该存入数据库。更一般的情况是，对于同样的一堆原始数据，统计时规定的条件不同，得到的结果固然也有所不同，并且都是用户所需的，这些数据该存在哪里呢。通常有这样两种方案，一种把生成的数据生成文本格式比如xml文件，上传到一个统一的位置，这样可以摆脱数据库表结构的束缚。用户查询时，系统只需要到这个位置把所有满足条件的文件列出来，用户选择哪个就转化为表格的规范形式打开那个文件。但是，这样有一个致命的缺点就是安全性太差，尤其是对于外部访问（指外部人员的访问也指外部网络的访问）。当然，虽然可以采用种种方式加强安全管理，但百密一疏的几率仍然很大，且实现复杂。

另一种方案就是把生成的数据都存放在数据库中，由于查询条件的不同，数据结构的不同，可能要分为多张临时表存储。但是，临时表的管理也不是件容易的事，开发人员往往会为了表的命名规则，数据如何检索，最终删除还是保留并且采用什么样的规则删除与保留而头痛不已。

显然，这些都不是好的办法，他们各有所长又各有所短，为何不把他们的优势组合一下呢。比如，可以将按照各种条件统计出来的数据集甚至是统计条件本身存放在XML文件中，然后将这些文件保存在数据库中一张结构固定的表内，实现和维护起来就方便了许多。检索时根据相关条件把XML文件取出来，格式化为规范的形式呈现，用户则丝毫感受不到这种方式与直接从数据库表中抽取普通数据的差异。