Sql Server报告服务与通过.NET应用程序的报告

Question

我的老板希望我在不久的将来创建一些报告，我想他想使用SQL Server Reporting Services部署报告。考虑到我们是一个非常小的组织，我不太确定这是一个好主意，我不能看到我们充分利用或需要此解决方案提供的功能，例如设置用户，组和订阅。

虽然我没有用SSRS之前，我看过就可以了为期3天的研讨会，它看起来像它的那些简单的情况下，很好的和确定的事情之一，而是成为一种痛苦&太受限制时要求变得更加复杂。我更部署在.NET应用程序的报告，当地媒体报道（.rdlc），因为：

1. 我宁愿处理&格式的数据与.NET则SQL。当然你可以使用CLR，但是这条路线看起来像维护困难并且不如我通常在.NET应用程序中处理数据那样理想。
2. 添加参数控件时对UI的限制 - 如果我记得您对布局没有太多控制权。

所以我想我的问题是在什么情况下SSRS工作良好，什么情况下工作不好？我的观点有效吗？还是我只是一个怀疑论者？

Answer 1

您可以像在Windows中一样设置报告服务的安全性，所以如果安全需求发生变化，您可以修改RS中的安全性。如果它嵌入到应用程序中，则必须更新应用程序（我没有这样做，因此我不知道所有步骤），然后重新部署应用程序以更新安全性。

Answer 2

你的观点是有效的。

对于一个较小的应用程序，如果你不需要所有的花里胡哨的东西，我会考虑在ASP.NET应用程序中使用ReportViewer控件。即使从维护的角度来看：你只需要管理一个应用程序。我的团队正计划停止使用SSRS。

我知道我们的一些姐妹团队有复杂的报告和结构，需要花里胡哨。

Answer 3

我使用了两者中的一小部分，并发现每种方法都存在权衡。

• 无论出于何种原因，.rdlc的设计者与.rdl的设计者有点不同。当一个在线的例子对你的设计师是什么进行假设时，它会变得相当混乱。
• 如果我试图成为客户端不可知的，我通常会倾向于SSRS部署的报告，因为基于.rdlc的报告要求您提供客户端。
• 我通常偏爱基于.rdlc的独立应用程序报告，特别是对于没有数据中心的客户。这些往往是应用程序和数据库都在客户机上的应用程序。
• 我喜欢LINQ，并且发现它更容易用作基于.rdlc的报告的数据源。
• 当谈到重构时，我对基于.rdlc的报告产生了爱/仇恨关系。将数据结构保存在不同于报告的独立库中非常重要;否则，更改属性名称会导致构建因报告而失败，但在构建之前，新属性在报表的数据源上不可用。
• 控制客户端（。基于rdlc的报告）为您呈现和收集参数值提供了无限灵活性，这非常好。

无论如何，我怀疑有任何教条的方法，你应该棒来，比“做什么是有道理的。”等对我而言，实际上，我为小型客户端应用程序使用基于.rdlc的报告，并将企业级报告部署到SSRS服务器。

祝你好运！

Answer 4

你的直觉很好，继续使用它们。

许多人陷入了将复杂的业务逻辑推入SQL和报表工具的陷阱。 ETL中适当的地方。不要被它涵盖复杂SSIS的简单ad-hoc perl脚本这个术语所吓倒。即使这样，有80％的时间人们会使用SSIS来提取和加载数据，以便在运行时保存报告的转换（为什么这些报告太慢？）。

即使您被迫通过SSRS提供数据，您的变换图层也必须与您选择的工具/语言中的报告分开，并保持您的sql简单明了。

对于一个小商店aspx可能没问题，但请记住这一点。你从SSRS获得免费的东西分配安全和出口到Excel是一个巨大的优势，为你的老板。报告也是忙碌工作的黑洞。您的第一批报告会因不同的用户和不同的业务原因而迅速增加，并变得难以管理。如果你设置了一个好的SSRS基地，那么当时间合适时，你可以将工作迁移到其他人。

如果您对我更感兴趣，我建议您阅读数据仓库。

还有一件事。请注意针对实时数据运行报告。报告通常具有与OLTP查询不同的性能配置文件。 OLTP =几个记录的时间报告（DW）查询有时需要全表扫描，并可能导致锁定问题，如果不正确设置。

Answer 5

没有人对Report Builder 2.0或3.0发表任何评论。这是一个伟大的应用程序，只是建立报告，而不需要任何SSRS或任何东西。只需启动它并设置它即可使用您拥有的任何数据源，并且您可以轻松前往。我的意思是，你可以很快地编写这份报告。想想看。

您绝对不需要为此定制另一个定制的.NET解决方案。

Getting Started with Report Builder 3.0