Sql Server Reporting Services 与通过 .NET 应用程序进行报告
我的老板希望我在不久的将来创建一些报告，我认为他想使用 SQL Server Reporting Services 来部署这些报告。我不太确定这是否是一个好主意，因为我们是一个相当小的组织，而且我看不到我们充分利用或需要该解决方案提供的功能，例如设置用户、组和订阅。
虽然我以前没有使用过 SSRS，但我看过一个为期 3 天的网络研讨会，看起来它对于简单的情况来说是很好的事情之一，但对于简单的情况来说却变得很痛苦。当需求变得更加复杂时，限制就太大了。 将报告部署为 .net 应用程序中的本地报告 (.rdlc)，因为：
- 我更愿意 先使用 .NET 格式化数据，然后使用 SQL。当然，您可以使用 CLR，但与我通常在 .NET 应用程序中处理数据相比，这种方法似乎更难维护，而且不太理想。
- 添加参数控件时 UI 的限制 - 如果我记得您对布局没有太多控制权。
所以我想我的问题是 SSRS 在什么情况下工作得很好，在什么情况下工作得不好？我的观点有效还是我只是持怀疑态度？
My boss wants me to create a few reports in the near future and I think he wants to use SQL Server Reporting Services to deploy the reports. I'm not so sure this would be such a great idea considering that we are a pretty small organization and I cannot see us making good use of or needing the features that this solution offers such as setting up Users, Groups and Subscriptions.
Although I have not used SSRS before, I've watched a 3-day webinar on it and it looks like it's one of those things that are nice and OK for simple situations but becomes a pain & too restricted when the requirements become more complex. I would much deploy the reports as local reports (.rdlc) in a .net application because:
- I would much rather process & format data with .NET then SQL. Sure you can use CLR, but this route just seems like it would be harder to maintain and less ideal than just processing data as I usually would in a .NET application.
- Limitations on UI when adding parameter controls - if I remember you do not have much control over the layout.
So I guess my question would be in what situations does SSRS work good, what situations does it not work good? Are my points valid or am I just being a skeptic?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您的积分有效。
对于较小的应用程序，如果不需要所有附加功能，我会考虑在 ASP.NET 应用程序中使用 ReportViewer 控件。即使从维护的角度来看：您只需要管理一个应用程序。我的团队计划停止使用 SSRS。
我知道我们的一些姐妹团队有复杂的报告和结构，并且需要附加功能。
Your points are valid.
For a smaller app, I'd consider using a ReportViewer control in an ASP.NET app if you don't need all the bells and whistles. Even from a maintenance perspective: you only have to manage one app. My team is planning to stop using SSRS.
I know some of our sister team have complex reports and structures, and need the bells and whistles.
没有人谈论 Report Builder 2.0 或 3.0。这是一个很棒的应用程序，只需构建报告，无需 SSRS 或任何其他东西。只需启动它并将其设置为使用您可用的任何数据源即可。我的意思是，您可以立即轻松地编写这份报告。想一想。
为此，您绝对不需要另一个定制的 .NET 解决方案。
报表生成器 3.0 入门
No one said anything about Report Builder 2.0 or 3.0. It is a great app just to build reports without any need of SSRS or anything. Just fire it up and set it up to consume whatever data source you have available and you are good to go. I mean, you can easily compile this report in no time. Think about it.
You definitely don't need another custom-tailored .NET solution for this.
Getting Started with Report Builder 3.0
你的直觉很好，继续使用它们。
许多人陷入了将复杂的业务逻辑推入 SQL 和报告工具的陷阱。正确的位置是在 ETL 中。不要被这个术语吓到，它涵盖了简单的临时 Perl 脚本到复杂的 SSIS。即使如此，80% 的时间人们只会使用 SSIS 来提取和加载数据，从而在运行时保存报告的转换（为什么这些报告如此慢？！）。
即使您被迫通过 SSRS 提供数据，也请使用您选择的工具/语言将转换层与报告分开，从而保持 sql 简单明了。
对于小商店来说，aspx 可能就可以了，但请记住这一点。您可以从 SSRS 获得大量免费的东西，并且安全性和导出到 excel 对您的老板来说是一个巨大的优势。报告也是繁忙工作的黑洞。由于不同的用户和不同的业务原因，您的第一批报告会迅速增加并变得难以管理。如果您建立了良好的 SSRS 基础，您可以在适当的时候将工作迁移给其他人。
如果您更感兴趣，我建议您阅读数据仓库。
还有一件事。请注意针对实时数据运行报告。报告通常具有与 OLTP 查询不同的性能配置文件。 OLTP = 一次只有几条记录，其中报告 (DW) 查询有时需要全表扫描，如果设置不正确，可能会导致锁定问题。
Your instincts are good, keep using them.
Many people fall into the trap of pushing complex business logic into SQL and reporting tools. The proper place is in the ETL. Don't be intimidated by the term it covers simple ad-hoc perl scrips to complex SSIS. Even then 80% of the time people will use SSIS to only Extract and Load data saving the transform for the report at run time (Why are these reports so slow?!).
Even if you are forced to serve the data via SSRS keep your transform layer separate from the report in the tool/language of your choice, keeping your sql simple and concise.
For a small shop aspx is probably fine but keep this in mind. You get allot of free stuff from SSRS with security and export to excel being a huge plus for you boss. Reports are also a black hole of busy work. Your first handful of reports quickly multiply for different users and different business reasons and become unmanageable. If you setup a good SSRS base you can migrate the work to someone else when the time is right.
If you are more interested I suggest reading up data warehousing.
One more thing. Be aware of running reports against live data. Reports typically have a different performance profile than OLTP queries. OLTP = a few records a time where Reporting (DW) queries sometime require full table scans and can cause locking issue if not setup properly.
您可以像在 Windows 中一样设置报告服务的安全性，因此如果安全性要求发生变化，您只需修改 RS 中的安全性即可。如果它嵌入在应用程序中，您必须更新应用程序（我没有这样做，所以我不知道所有步骤），然后重新部署应用程序以更新安全性。
You can set up the security for Reporting services just like in windows, so if a security requirment changes you can just modify the security in RS. If it's embedded in an application you'd have to update the application (i haven't done this so i don't know all of the steps) and then redeploy the application to update the security.
我使用了这两种方法，并且发现每种方法都需要权衡。
无论如何，我怀疑除了“做有意义的事”之外，您还应该坚持任何教条的方法。对我来说，在实践中，我将基于 .rdlc 的报告用于小型客户端应用程序，并将企业级报告部署到 SSRS 服务器。
祝你好运！
I use a little of both, and have found that there are trade-offs with each approach.
At any rate, I doubt there is any dogmatic approach you should stick to, other than "do what makes sense." For me, in practice, I use .rdlc-based reports for small client applications, and deploy enterprise-grade reports to a SSRS server.
Good luck!