我已经使用了Cognos Series 7，Cognos Series 8，Crystal Reports，Business Objects XI R2
WebIntelligence，Reporting Services 2000，Reporting Services 2005和Reporting
Services2008。这是我对所学知识的反馈：

报表服务2008/2005/2000

优点

1. 成本：如果您使用MS SQL Server作为后端，则是最便宜的企业商业智能解决方案。如果您投身SSIS，您也可以免费获得一流的ETL解决方案。

2. 最灵活：我曾经使用过的最灵活的报告解决方案。它始终满足了我的所有业务需求，尤其是在最新的化身中。

3. 易于扩展：我们最初将其用作支持大约20个用户的部门解决方案。我们最终将其扩展到覆盖数千名用户。尽管位于远程数据中心的虚拟服务器的质量确实很差，但我们仍能够扩展到大约50-100个并发用户请求。在一个咨询公司的优质硬件上，我能够将它扩展到更多并发用户，而没有任何问题。我还看到了在不同国家/地区部署了多个SSRS服务器并使用SSIS同步后端数据的实现。这样就可以以分布式方式实现稳定的性能，而几乎不需要增加任何成本。

4. 源代码控制集成：与我的商业智能团队一起开发报告时，这对我来说至关重要。没有其他BI套件可以为我使用过的现成的解决方案。我使用的所有其他平台都需要购买第三方插件，或者需要您在单独的开发，测试和生产环境之间升级报告。

5. Analysis Services：我喜欢SSRS和SSIS之间与Analysis Services的紧密集成。我已经阅读了有关Oracle和DB2引号包括为OLAP多维数据集安装SQL Server 2005 Analysis Services服务器的实例。

6. 可发现性：没有系统比SSRS具有更好的可发现性。SSRS上的书籍，论坛，文章和代码站点比我使用过的任何其他BI套件都要多。如果我需要弄清楚如何在SSRS中做某事，几乎可以花几分钟或几小时来找到它。

缺点

1. SSRS 2005/2000所需的IIS：较旧版本的SSRS要求在数据库服务器上安装IIS。从内部控制的角度来看，当我在一家大型银行工作时，这是不允许的。我们最终在未经IT运营授权的情况下实施了SSRS，后来基本上要求宽恕。 由于不再需要IIS，所以在SSRS 2008中这不是问题。

2. 报表生成器：SSRS 2000中不存在基于Web的报表生成器。SSRS2005中基于Web的报表生成器难以使用且功能不足。SSRS 2008中的基于Web的报表生成器绝对更好，但是对于大多数企业用户来说仍然很难使用。

3. 数据库偏差：与Microsoft SQL Server配合使用效果最佳。对于Oracle，DB2和其他后端来说，这不是很好。

业务对象XI WebIntelligence

优点

1. 易于使用：最适合普通的非BI最终用户开发临时报告。

2. 不可知的数据库：如果您希望使用Oracle，DB2或另一个数据库后端，绝对是一个好的解决方案。

3. 性能：非常快的性能，因为大多数页面导航基本上都是文件系统操作，而不是数据库调用。

缺点

1. 成本：第一个问题。如果我要将Business Objects的实现从30个用户扩展到1000个用户，那么SAP一定会向您收取数十万美元的费用。这仅适用于Business Objects许可证。加上您还将需要数据库服务器许可证这一事实，您现在正在谈论的是非常昂贵的系统。当然，这可能是获得Business Objects的个人理由：如果您可以说服管理层购买非常昂贵的BI系统，那么您就可以说服管理层为大型BI部门付费。

2. 没有源代码控制：缺少现成的源代码控制集成会导致错误地意外修改和部署旧报表定义。为此，“解决方法”是在环境之间升级报告，我不喜欢这样做，因为它会减慢报告的开发速度并引入环境差异变量。

3. 不支持HTML电子邮件：您无法通过计划发送HTML电子邮件。我经常在SSRS中这样做。您可以购买昂贵的第三方插件来执行此操作，但是您不必为此功能花费更多的钱。

4. 模型偏差：报表开发需要Universe-本质上是数据模型。这对于临时报表开发很好，但是我更喜欢使用存储过程来完全控制性能。我还喜欢构建平面表，然后查询这些平面表，以避免在报表运行时花费高昂的复杂联接。必须构建仅包含仅由一个报表使用的平面表的Universe是很愚蠢的。您不必仅查询表就可以构建模型。如果不破解SQL覆盖，也无法立即支持存储过程支持。

5. 较差的参数支持：BOXI WebIntelligence报表中的参数支持很差。尽管我喜欢普通业务用户的元数据刷新选项，但是在尝试设置计划时它不够强大。我几乎总是必须克隆报告并略微更改过滤器，这导致不必要的报告定义重复。SSRS击败了这一手，特别是因为您可以使值和标签具有不同的值-与BOXI不同。

6. 报表链接支持不足：我想将一个报表定义存储在中央文件夹中，然后为其他用户创建链接的报表。但是，我很快发现最终用户需要对父对象具有完全权限才能使用其自己的文件夹中的对象。这违反了使用链接的报表对象的全部目的。给我SSRS！

7. 单独的CMC：为什么仅为了管理对象安全性而必须启动另一个应用程序？更糟糕的是，为什么CMC和InfoSys之间的功能不相同？例如，如果要设置计划的报告以重试失败的尝试，则可以在CMC中指定重试次数和重试间隔。但是，您无法在InfoSys中执行此操作，也看不到任何信息。InfoSys允许您设置事件驱动的日程表，而CMC不支持此功能。

8. Java版本依赖性：BOXI在最终用户计算机上运行良好，只要它们与服务器运行的Java版本相同即可。但是，一旦在计算机上安装了Java的较新版本，事情就会开始崩溃。我们在BOXI R2服务器（默认的Java客户端）上运行Java 1.5，并且公司中几乎每个人都在Java 1.6上运行。如果使用Java 1.6，则提示可能会冻结IE和FoxFire会话，或者使报告生成器意外崩溃。

9. 薄弱的可发现性：除了BOB（Business Objects Board，业务对象委员会）之外，Internet上没有很多有关对Business Objects问题进行故障排除的方法。

Cognos系列8

优点

1. 易用性：尽管BOXI更易于使用，可以为一般业务用户编写简单的报告，但Cognos在该领域排名第二。

2. 与数据库无关：如果您希望使用Oracle，DB2或另一个数据库后端，那么与BOXI一样，这绝对是一个不错的解决方案。

3. FrameWork Manager：这绝对是同类中最好的元数据存储库。BOXI的宇宙建造者希望它能好一半。该工具非常适合在开发，测试和生产环境中推广软件包。

缺点

1. 成本：与业务对象相同的问题。相似的成本结构。相似的数据库许可要求也是如此。

2. 无源代码控制：与业务对象相同的问题。我不知道有任何第三方工具可以解决此问题，但是它们可能存在。

3. 模型偏差：与业务对象相同的问题。不过，它对FrameWork Manager中的存储过程有更好的支持。

4. 参数支持差：与业务对象相同的问题。如果可以使用Java编写代码，则对创建提示页面有更好的支持。但是，当用户单击后退按钮以返回到提示页面时，会出现错误的行为。SSRS击败了这一点。

5. 错误的处理不当：几乎无法破译Cognos中的错误消息。作为错误消息的一部分，它们通常会给您一个长的负数和一个堆栈转储。我不知道我们有多少次通过从头开始重建报告来“解决”这些错误消息。由于某些原因，破坏报告定义非常容易。

6. 无可发现性：很难找到有关如何解决问题或在Cognos中实现功能的任何答案。面向Internet的网站中针对这些产品的社区支持不足。

您可以从我的答案中猜到，我相信微软的BI套件是市场上最好的平台。但是，我必须指出，我阅读过的关于BI套件比较的大多数文章通常不评价Microsoft的产品以及SAP的Business
Objects和Cognos的Series 8产品。另外，在上任的首席信息官（CIO）对BI Suites进行内部审查之后，我还看到Microsoft在BI
Suites的内部审查中排在最后。但是，在这两种情况下，似乎都归结为希望被视为有理由证明拥有大量运营预算的主要部门。