每个项目总是需要某种类型的报告功能。从您选择的语言中的 foreach 循环到完整的 BI 平台。
为了完成工作,团队使用了哪些工具、小部件、平台来实现成功、挫折和失败?
每个项目总是需要某种类型的报告功能。从您选择的语言中的 foreach 循环到完整的 BI 平台。
为了完成工作,团队使用了哪些工具、小部件、平台来实现成功、挫折和失败?
对于淘汰相当“普通”的报告,SQL Reporting Services 确实令人印象深刻。
对于复杂的分析,将数据(可能是预先聚合的)加载到 Excel 数据透视表中对于大多数用户来说通常就足够了。
我发现您可以花费大量时间(和金钱)来构建一个全面的“临时”报告套件,并且在“令人惊叹的因素”的第一个月或两个月之后,生成的 99% 的报告将是相同的报告一组固定参数的细微差别。
当用户说他们想要“临时”报告但没有指定他们寻找的目标和目标时,不要接受。他们只是在钓鱼,他们实际上需要花费尽可能多的时间来考虑他们的报告要求,就像您必须花费在构建他们的解决方案上一样。
我花了太多时间来构建“可以报告一切的系统”,并且在它完成之前就已经过时或失宠。最好尽可能快地消除快速的胜利,然后花时间“系统化”最重要的报告。
对于大多数报告,我们使用BIRT。
我已经相当广泛地使用了 Reporting Services 和 Crystal,目前我正在使用 Excel(ick) 编写一些报告。
Reporting Services 非常适合简单的报告,但只要您需要完全控制格式、复杂的公式和图表等。Crystal 是一个很长的路要走。我还发现 Crystal 更实用。能够在报告预览中更改内容是非常宝贵的(在 RS 的更高版本中可能?)。
如果您正在编写需要在外部部署的应用程序,RS 还需要部署到 Web 服务器,这限制了它的用处。
Crystal 的旧版本有很多错误,但最新版本要好得多,它比 Reporting Services 成熟得多。
对于很多项目,我们使用 ActiveReports。
我是 BIRT 项目的提交者,所以我有偏见。BIRT 为所需的各种设计和部署功能提供了一个经过深思熟虑的报表对象模型 (ROM) 和适当的 API。此外,BIRT 提供了最好的多语言支持和通过使用 CSS 将开发与设计分离的能力。
BIRT 可以通过 REAPI 免费嵌入到您的应用程序中,也可以通过几个商业产品购买。
Cognos 是一套强大的工具(我们将其用作 Oracle 后端的前端),但明显缺乏关于如何完成复杂报告任务的文档——大多数情况下,您最终会敲打它,直到您得到一些工作。
我不会低估使用 Microsoft Access 作为报告前端的用处。它没有那种有用的支持 Web 的功能,但对于内部报告来说,它非常通用且功能强大。
我们使用i-net Clear Reports进行报告(看看我们如何“吃自己的狗粮”)。;)
如果您拥有世界上所有的钱,请选择 Cognos。它们提供了一个数据立方体,基本上使报告“无需开发人员”,最终用户可以创建报告、仪表板,以及他们喜欢的任何东西。
对于“普通人”,我已经非常喜欢 ComponentOne 报告的 .NET 库/工具。它与 Crystal Reports 有相似的感觉,但有一个非常友好的 XML 格式,您可以在后台进行编辑,并且在对其中任何一个进行简单更新时,我都必须处理版本控制、密钥和其他项目。报告或基础版本。
我真的没有太多的 SSAS 工作要做,但我对此很感兴趣:
它在 Web 应用程序中提供了 excel 数据透视表的许多功能,(我认为我不是 Excel 专家,无法真正了解数据透视表的全部功能 - 它至少看起来可以与 Visual Studio 的立方体浏览器相媲美) .
不幸的是,演示似乎不再在线了:(
我不得不同意,我真的很喜欢 SQL Server Reporting Services。它只是做一些事情,并且很容易做到。
Crystal Reports,因为很容易获取完全相同的报表文件和
1 - 在 Intranet 上发布
2 - 将其嵌入到应用程序中
3 - 定期将其作为 Excel 输出通过电子邮件发送给需要它的人
此外(正如我已经建议的),它可以轻松导出为 Excel、PDF 和其他格式。
我们一直在使用 BIRT,它对我来说学习曲线陡峭,直到我意识到它有多少所见即所得的功能(我开始直接编辑 xml 源代码,我不推荐这样做。)有一些特定于输出的技巧(比如使用一个 0 左边距以在输出为 XLS 格式时不会得到一个空白的 A 列),但在大多数情况下,它使用、编辑和预览快速且易于使用。
在一个报告中混合不同的数据集是多么容易,这给我留下了深刻的印象。虽然不是灵丹妙药,但它是一个比 99.999% 的人自己构建的更好的全方位工具。
“给他们数据,他们会因此而爱你”
在我过去使用过的方法和工具中,我会根据能力/多功能性/可用性/部署速度按以下顺序对它们进行排名。我将成本排除在外,因为虽然它始终是一个因素,但对每个人来说都是一个不同的因素。
1 是 Cognos(版本 8)
2 是 SQL Server 报告
3是水晶报表
4是自定义编写的代码
我没有使用任何提到的其他工具。Cognos 8 简直太棒了。虽然价格昂贵,但您只受想象力的限制。它可以做任何事情。
这不是一个积极的建议,而是一个针对水晶报告的警示故事......与其他人一样,获得正确版本的水晶运行时很重要,但是这样做了,我仍然遇到了这个问题:
花了两周的时间在论坛上搜索并寻求建议,最终在他们的论坛上得到了一个水晶体的回应。建议他看到了与将 MS Paint 设置为某个文件扩展名的默认应用程序有关的类似问题。
在这一点上,我们放弃了尝试(在我说服我的老板这不是小便的答案,而是水晶的正式回应之后)。大约一个月后,我们很方便地迁移到新服务器(报告工作的地方),但老实说,不会再碰它们了......
哦,并且使用过 SSRS 并发现它对于大多数事情(尤其是最新版本)都非常好。
Tableau 软件是运行报告并轻松进行深入分析的绝佳工具
对于简单的报告,我使用 Visual Studio 中包含的标准 ReportViewer。
对于更复杂的报告和需要更高性能的报告,我使用了 Report Sharp Shooter 和 devExpress XtraReports。令人惊讶的是,在这两种产品中创建表格并不像应有的那么容易,但它们都比 ReportViewer 更快,并且可以很好地处理多列报告、条形码和聚合数据。
我们使用 Cognos,它是一个相当复杂的系统,但非常强大。
我有一个小型报告集,在 2 个月内完成:
至少比水晶报告快10倍;
易于编辑;
.net 公式;
易于使用;
小代码使用;
序列化和反序列化(快速和小型);
极度安全;
多线程;
没有错误;
我们曾经使用过 MS Reporting Services,但我们对此完全不满意。原因:
现在我们使用 Stimulsoft Reports。它没有像 MS Reporting Services 这样的限制,我们和您的用户都对它感到满意。
1) 我认为 Reporting Services 非常适合大多数需求,在开发基于表格的报告和矩阵报告(向下钻取 - 类似于枢轴的功能)时。考虑到 Cognos 等的价格。中小企业甚至做梦都做不到获得 Congns AFAIK
2) 可以调用报告计划/订阅功能将报告发送给一组用户(数据驱动)以交付报告。通过编写 .Net 代码,可以将订阅交付到自定义位置,例如 SFTP。
3) 使用报表模型,最终用户可以拖放列并开发自定义报表
要注意:
1)一旦您开发了非常复杂的图形/仪表板类型的报告,它可能会变得更加棘手 - 其中涉及在 A4 中显示的少量图表和小表格。报表设计器(我们用来设计报表的工具)和 Web 显示使用不同的渲染引擎。因此,如果您开发复杂的图形报告,最好经常部署报告并查看它们的外观
2) 如果您编写自定义功能,您可能需要更改 XML 配置文件(RSReportServer.Config 等)。如果编辑有任何问题,ReportServer 服务可能会停止。所以在做任何自定义之前要小心备份
我们使用的是带有 Oracle 后端的 Cognos。我们还在 cognos 之上使用 spotfire 进行可视化。
我是 Windward 的首席技术官,我相信Windward 报告是迄今为止最容易使用的,而且你可以用它做更多的事情而不是其他任何报告 - 这两个特点是出于相同的原因,你在 Word 中设计你的报告, Excel 和 PowerPoint。
至于生成的报告,它速度快、坚如磐石,将其合并到您的程序中只需 3 行代码。
我们在我工作的地方使用 Crystal Reports。它有很多限制,我们发现自己几乎完成了数据库过程和视图中的所有逻辑。
需要注意的一个限制是 Crystal Reports 不允许多层子报表。换句话说,您不能在子报告中包含子报告。