如何选择Web报表工具
报表，是许多应用系统中非常重要的组成部分。
报表工具，是高效率开发和运行报表的关键。今天，已经没有人再会用手工编写代码的方法来制作报表了吧。
目前，已经有了不少报表工具可供选择，各厂家做足宣传，产品功能令人眼花瞭乱。本文将从B/S应用的角度，专注于Web报表工具，谈谈如何以一个合理的方法，选择Web报表工具。
选择Web报表工具的基本次序是：硬指标满足 - 报表的可实现性 - 综合成本 - 系统的可靠性与性能
1. 硬指标满足：
硬指标是指一些对Web报表工具很明确的、必须要满足的要求。这种指标每个项目都会不同，但往往都是对用户和开发商很关键的。比如，有时会要求能在Linux平台下运行，有时会要求能将报表转出为PDF，有时会要求能将产品的标记改为项目开发商或用户的(OEM),有的要求Java报表,有的要求离线填报，有的要求客户端无控件... ...。并不是说一定要满足上面的指标，而是说，对于这类的指标，应该一开始就列清楚，要明确问明白被选择的产品能不能满足，对于不能满足的产品，就完全没必要再浪费时间了。
之所以把这个工作放在第一步，一方面是因为这是很重要的环节，另一方面是因为这个工作花费的时间少，用它来进行第一步的筛选，最节省时间。
同时在这里列出一些常见Web报表工具在“硬指标”方面的情况：
跨平台部署：这方面Style Report, 润乾报表都支持得很好。杰表虽然是Java的，但有用户反映在UNIX下有困难。Crystal Report/BO, Brio等产品由于其体系结构原因，实际在Unix下部署很困难。其他一些基于控件的低端产品就很难讲了。
HTML展现：这方面象润乾，杰表，Crystal Report，Style Report等Web报表工具都没有问题，但基于控件的低端Web报表产品如数巨、明宇就有很大缺陷。
OEM及开发接口：这方面国内产品普遍没有问题，但国外产品则都做不到OEM。开发接口方面，润乾的Java开发接口应该说是最强大的，Crystal Report则在.NET方面比较强。
填报：这方面国内Web报表产品一般都支持填报功能（具体强弱有差异），但国外产品则都做不到。
2. 报表的可实现性：
一个Web报表工具再好，再便宜，或是再有名，要是你要的报表做不出来，别的全是瞎扯。
所以，一定要弄清楚，客户要什么样的报表，要拿到一些典型的表样。
如果你的报表很简单，把数据挑几列一行行列出来，那每个产品都能做。
如果你的报表很复杂，特别是里面有些很别扭的东西，恐怕就会有很多产品做不了了。
这一步，最省事的方法，是拿着要做的报表，给Web报表产品厂商看一下，让他们说句痛快话，能做不能做。
但是，销售有一句名言：使劲拍胸脯，哪怕拍成鸡胸。所以，厂商很可能会告诉你他们都能做，但到最后，你会发现做不了。
因此，还是要对常规的报表制作方法有一个基本了解。最简单的，打开MS Access，就有一个内置的报表工具，这是报表的老鼻祖了，大多数报表工具，都是从这种模式传承下来的，当然做了很多的改良。当你了解了一般的报表路数，你就会比较容易明白，哪些东西对于报表工具是小菜一碟，几乎谁都能做，哪些东西则有难度，甚至很难做。对于后者，你可以集中精力，了解一下你选择的产品能不能做，怎么实现。当你认真去探讨时，做得了、做不了，也就会比较清楚了。
这里面会出现一个问题，有些报表，拿有的工具就是做不出来，那很简单，直接PASS掉。但有些报表，在有些Web报表工具下可以很简单地做出来，在有些工具下则可以用一些曲折的方法做出来，这时就不能简单地比较产品了，要去比较综合拥有成本。
在这个方面，大多数产品，以Crystal Report，Style Report为代表，都是传统的模型，只是适合比较简单的报表，而对于复杂的报表，有些需要编程来实现，有些则根本实现不了。国内有些产品如杰表在设计模式上进行了一些小的改进，而改进最大的则是润乾报表，采用了新的报表模型，在处理各种复杂报表方面优势很大。（可以参考：新一代报表工具–报表设计的革命）
3. 综合成本
是不是一张报表，一个工具五分钟做出来，另一个Web报表工具半天做出来，前者就一定好呢？（这是象润乾这样的产品所经常宣称的）
是不是两个Web报表工具（或者说BI工具），一个能做十件事，另一个只能做三件事，前者就一定好呢？（这是象BO、Brio这样的产品所经常宣称的）
是不是两个Web报表工具，一个卖十块钱，另一个卖一百块钱，前者就一定更合算呢？（这是有些Web报表工具所乐于宣称的，仅需xxx元...）
未必吧！
单张设计效率高，如果报表少，如果报表简单，有什么用？
一大堆功能，用户用不上，有什么用？
买工具便宜，开发花一大堆钱，合算吗？
当问题这样直接问出来时，恐怕很多人都能做出正确的回答了。
真正正确的方法，是考察综合拥有成本。综合拥有成本，是为了达到目标（用户的实际需要），所花费的购买工具、开发、机会成本等等的总和。
请你明确一下用户到底需求的是什么；他的报表是什么样子；他的报表有多少；还有，你自己的人员成本是多少！
另外计算一下你有多少人，项目的进度要求... ...
看看用每个报表工具，你要花多少钱，你要花多少精力与人力投入... ...
根据这些，做出一个综合评估，你就会很明确，哪个是对你最合算的选择。
举两个极端的例子，用户就10张报表，你的程序员不用花钱（不管你用什么办法），那你干脆找个开源的，自己改改吧。
反之，用户有500张报表，很复杂，你的程序员一个人月的成本是2万（不光是工资，你还要付福利、房租、空闲成本、培训成本、管理分摊...），那你选一个报表工具比另一个便宜五万块钱，有多大用吗？
这里有两点要明确。一是算综合成本，前提是“能做”，即我们所说的可实现性。二是算综合成本，是建立在一个假设的基础上，即你相信厂商所说的。后面你还需要实际去试试。
这方面的情况是，有低端的Web报表产品，如开源的、杰表、数巨、明宇，大概在0-几千元，定位于报表数量少、报表简单的应用，高端的产品在十万元量级如BO、Brio定位于复杂的OLAP应用，Crystal Report、Style Report等大约是一万至几万的量级，定位于具有一定复杂度的应用。而润乾则目前推出了全系列的Web报表产品线，从千元到几十万元，以适合不同应用的需要。
在综合成本方面，更长远一点考虑，就是如果你是一个开发商，你不光要考虑一个项目的综合成本，还要考虑长期应用的综合成本，如果你有些项目简单，有些项目复杂，那么选择象润乾这样的全系列Web报表产品会更有助于技术体系的统一性。实际上对于复杂的大型项目，几乎润乾是唯一合适的选择，但以前润乾集中于高端应用，对简单报表应用的用户不太适合，现在则推出了低端版本，可以很灵活地适应低端用户的需要。
4. 系统的可靠性与性能
到这一步，你应该是有一个优选的产品了。
为什么到这一步才去试，是因为系统的可靠性与性能，试起来都要花费你大量的精力。如果拿好几个产品试，不仅浪费时间，而且可能会使你无法真正把一个产品试深入。
至于说应该如何试、试到什么程度，看你的经验、判断及厂商的相关情况等等了。
不过，在试验之前，首先要从理论上进行一下了解：
- Crystal Report, Style Report，作为国际知名产品，其可靠性是很有保障的。国内一些比较知名的Web报表产品，如润乾、杰表，可靠性也是不错的。一些太小的或者炒作大于实际的所谓大公司，以及开源的产品，其可靠性就谈不上保障了。
- Style Report、润乾、杰表作为Java报表工具，可以在大型服务器上运行，可以充分利用应用服务器的负载均衡、数据库连接池等，因此性能方面有很大优势。Crystal Report为代表的产品是基于独立服务器的，在一般规模的应用下应无问题。而数巨、明宇等基于控件的Web报表产品，其机制是前端控件中完成报表计算，这种机制对于大型、复杂报表或者大面积应用都是不适合的。
总的讲，以下关于Web报表的选择建议可供参考：
- 大型或中型Java报表应用，选择润乾报表
- 一般的.NET应用，选择Crystal Report(也可以考虑润乾)
- 小型Web报表应用，Java的选择润乾的低端版本或杰表，ASP和.NET的选择数巨、明宇，如果实在不想花钱，可以选择开源的（其实更主要的是从学习角度）。
- 作为产品选型或开发商长期的技术选型，除非是专注于.NET，否则一定要选择润乾（注意可以与润乾谈一个打包的方法，避免一套套购买成本太高）。
http://www.blog.com.cn/user7/20839/archives/2005/134730.shtml
他们设置了哪些标签：
报表
谁收藏了这个网址：
使用标签：报表，时间：2007-3-28 13:14:46 | 相关网摘
报表，是许多应用系统中非常重要的组成部分。
报表工具，是高效率开发和运行报表的关键。今天，已经没有人再会用手工编写代码的方法来制作报表了吧。
目前，已经有了不少报表工具可供选择，各厂家做足宣传，产品功能令人眼花瞭乱。本文将从B/S应用的角度，专注于Web报表工具，谈谈如何以一个合理的方法，选择Web报表工具。
选择Web报表工具的基本次序是：硬指标满足 - 报表的可实现性 - 综合成本 - 系统的可靠性与性能
1. 硬指标满足：
硬指标是指一些对Web报表工具很明确的、必须要满足的要求。这种指标每个项目都会不同，但往往都是对用户和开发商很关键的。比如，有时会要求能在Linux平台下运行，有时会要求能将报表转出为PDF，有时会要求能将产品的标记改为项目开发商或用户的(OEM),有的要求Java报表,有的要求离线填报，有的要求客户端无控件... ...。并不是说一定要满足上面的指标，而是说，对于这类的指标，应该一开始就列清楚，要明确问明白被选择的产品能不能满足，对于不能满足的产品，就完全没必要再浪费时间了。
之所以把这个工作放在第一步，一方面是因为这是很重要的环节，另一方面是因为这个工作花费的时间少，用它来进行第一步的筛选，最节省时间。
同时在这里列出一些常见Web报表工具在“硬指标”方面的情况：
跨平台部署：这方面Style Report, 润乾报表都支持得很好。杰表虽然是Java的，但有用户反映在UNIX下有困难。Crystal Report/BO, Brio等产品由于其体系结构原因，实际在Unix下部署很困难。其他一些基于控件的低端产品就很难讲了。
HTML展现：这方面象润乾，杰表，Crystal Report，Style Report等Web报表工具都没有问题，但基于控件的低端Web报表产品如数巨、明宇就有很大缺陷。
OEM及开发接口：这方面国内产品普遍没有问题，但国外产品则都做不到OEM。开发接口方面，润乾的Java开发接口应该说是最强大的，Crystal Report则在.NET方面比较强。
填报：这方面国内Web报表产品一般都支持填报功能（具体强弱有差异），但国外产品则都做不到。
2. 报表的可实现性：
一个Web报表工具再好，再便宜，或是再有名，要是你要的报表做不出来，别的全是瞎扯。
所以，一定要弄清楚，客户要什么样的报表，要拿到一些典型的表样。
如果你的报表很简单，把数据挑几列一行行列出来，那每个产品都能做。
如果你的报表很复杂，特别是里面有些很别扭的东西，恐怕就会有很多产品做不了了。
这一步，最省事的方法，是拿着要做的报表，给Web报表产品厂商看一下，让他们说句痛快话，能做不能做。
但是，销售有一句名言：使劲拍胸脯，哪怕拍成鸡胸。所以，厂商很可能会告诉你他们都能做，但到最后，你会发现做不了。
因此，还是要对常规的报表制作方法有一个基本了解。最简单的，打开MS Access，就有一个内置的报表工具，这是报表的老鼻祖了，大多数报表工具，都是从这种模式传承下来的，当然做了很多的改良。当你了解了一般的报表路数，你就会比较容易明白，哪些东西对于报表工具是小菜一碟，几乎谁都能做，哪些东西则有难度，甚至很难做。对于后者，你可以集中精力，了解一下你选择的产品能不能做，怎么实现。当你认真去探讨时，做得了、做不了，也就会比较清楚了。
这里面会出现一个问题，有些报表，拿有的工具就是做不出来，那很简单，直接PASS掉。但有些报表，在有些Web报表工具下可以很简单地做出来，在有些工具下则可以用一些曲折的方法做出来，这时就不能简单地比较产品了，要去比较综合拥有成本。
在这个方面，大多数产品，以Crystal Report，Style Report为代表，都是传统的模型，只是适合比较简单的报表，而对于复杂的报表，有些需要编程来实现，有些则根本实现不了。国内有些产品如杰表在设计模式上进行了一些小的改进，而改进最大的则是润乾报表，采用了新的报表模型，在处理各种复杂报表方面优势很大。（可以参考：新一代报表工具–报表设计的革命）
3. 综合成本
是不是一张报表，一个工具五分钟做出来，另一个Web报表工具半天做出来，前者就一定好呢？（这是象润乾这样的产品所经常宣称的）
是不是两个Web报表工具（或者说BI工具），一个能做十件事，另一个只能做三件事，前者就一定好呢？（这是象BO、Brio这样的产品所经常宣称的）
是不是两个Web报表工具，一个卖十块钱，另一个卖一百块钱，前者就一定更合算呢？（这是有些Web报表工具所乐于宣称的，仅需xxx元...）
未必吧！
单张设计效率高，如果报表少，如果报表简单，有什么用？
一大堆功能，用户用不上，有什么用？
买工具便宜，开发花一大堆钱，合算吗？
当问题这样直接问出来时，恐怕很多人都能做出正确的回答了。
真正正确的方法，是考察综合拥有成本。综合拥有成本，是为了达到目标（用户的实际需要），所花费的购买工具、开发、机会成本等等的总和。
请你明确一下用户到底需求的是什么；他的报表是什么样子；他的报表有多少；还有，你自己的人员成本是多少！
另外计算一下你有多少人，项目的进度要求... ...
看看用每个报表工具，你要花多少钱，你要花多少精力与人力投入... ...
根据这些，做出一个综合评估，你就会很明确，哪个是对你最合算的选择。
举两个极端的例子，用户就10张报表，你的程序员不用花钱（不管你用什么办法），那你干脆找个开源的，自己改改吧。
反之，用户有500张报表，很复杂，你的程序员一个人月的成本是2万（不光是工资，你还要付福利、房租、空闲成本、培训成本、管理分摊...），那你选一个报表工具比另一个便宜五万块钱，有多大用吗？
这里有两点要明确。一是算综合成本，前提是“能做”，即我们所说的可实现性。二是算综合成本，是建立在一个假设的基础上，即你相信厂商所说的。后面你还需要实际去试试。
这方面的情况是，有低端的Web报表产品，如开源的、杰表、数巨、明宇，大概在0-几千元，定位于报表数量少、报表简单的应用，高端的产品在十万元量级如BO、Brio定位于复杂的OLAP应用，Crystal Report、Style Report等大约是一万至几万的量级，定位于具有一定复杂度的应用。而润乾则目前推出了全系列的Web报表产品线，从千元到几十万元，以适合不同应用的需要。
在综合成本方面，更长远一点考虑，就是如果你是一个开发商，你不光要考虑一个项目的综合成本，还要考虑长期应用的综合成本，如果你有些项目简单，有些项目复杂，那么选择象润乾这样的全系列Web报表产品会更有助于技术体系的统一性。实际上对于复杂的大型项目，几乎润乾是唯一合适的选择，但以前润乾集中于高端应用，对简单报表应用的用户不太适合，现在则推出了低端版本，可以很灵活地适应低端用户的需要。
4. 系统的可靠性与性能
到这一步，你应该是有一个优选的产品了。
为什么到这一步才去试，是因为系统的可靠性与性能，试起来都要花费你大量的精力。如果拿好几个产品试，不仅浪费时间，而且可能会使你无法真正把一个产品试深入。
至于说应该如何试、试到什么程度，看你的经验、判断及厂商的相关情况等等了。
不过，在试验之前，首先要从理论上进行一下了解：
- Crystal Report, Style Report，作为国际知名产品，其可靠性是很有保障的。国内一些比较知名的Web报表产品，如润乾、杰表，可靠性也是不错的。一些太小的或者炒作大于实际的所谓大公司，以及开源的产品，其可靠性就谈不上保障了。
- Style Report、润乾、杰表作为Java报表工具，可以在大型服务器上运行，可以充分利用应用服务器的负载均衡、数据库连接池等，因此性能方面有很大优势。Crystal Report为代表的产品是基于独立服务器的，在一般规模的应用下应无问题。而数巨、明宇等基于控件的Web报表产品，其机制是前端控件中完成报表计算，这种机制对于大型、复杂报表或者大面积应用都是不适合的。
总的讲，以下关于Web报表的选择建议可供参考：
- 大型或中型Java报表应用，选择润乾报表
- 一般的.NET应用，选择Crystal Report(也可以考虑润乾)
- 小型Web报表应用，Java的选择润乾的低端版本或杰表，ASP和.NET的选择数巨、明宇，如果实在不想花钱，可以选择开源的（其实更主要的是从学习角度）。
- 作为产品选型或开发商长期的技术选型，除非是专注于.NET，否则一定要选择润乾（注意可以与润乾谈一个打包的方法，避免一套套购买成本太高）。