报告解决方案
我正在征求有关报告解决方案的建议
。我们开发了很多内部项目（.net 和 sql server）。对于较大的数据库，我们使用业务对象并构建用于报告的宇宙，以便分析师或报告编写者可以构建报告，而开发人员不需要参与。
我们的许多项目都包含重要数据，但规模不够大，无法容纳在其上构建的宇宙和数据仓库。我们仍然需要根据这些数据构建报告，但我们不想报告实时数据库，因为这可能会影响应用程序的性能。对于我们的一些项目，我们每晚进行备份/恢复，有效地复制数据库，然后使用该副本作为报告数据库。由于没有太多的报告经验，我想知道人们还实施了哪些其他解决方案。
I am soliciting for suggestions on reporting solutions
We develop a lot of in house projects(.net and sql server). For larger database we use business objects and build universes for reporting so that analysts or report writers can build reports and developers dont need to be involved.
Many of our projects house important data, but are not large enough to warrent universes and data warehouses being built on them. We still need to build reports off of this data but we don't want to report off the live databases as that could affect performance of the applications. For some of our projects, we do nightly backups/restores, effectively duplicating the database and then use the copy as a reporting database. Not having a lot of reporting experience, I'm wondering what other solutions people have implemented.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在这种情况下，我们从以下位置设置了事务复制 OLTP 数据库到用于报告目的的辅助数据库。
In situations like this, we've set up transactional replication from the OLTP database to a secondary database that is used for reporting purposes.
如果您运行的是 2008，您可以使用资源调控器来限制报告用户对生产数据库服务器的 CPU 和内存使用情况。最好的情况是拥有专用的报告服务器和数据库，但这可以工作。
If you are running 2008 you can use the resource governor to limit cpu and memory usage on your production database server by your reporting users. Best scenario is to have a dedicated reporting server and db, but this can work.
最简单的方法是设置一个用于报告的服务器并将数据库复制到该服务器上。针对报告服务器运行报告。
这对于报告来说可能不是很有效，并且如果您的报告工作负载很大，则可能会出现性能问题。
根据您的报告要求，您可能需要介于数据仓库和针对操作数据库副本的一套报告之间的东西。更简单的、系统特定的扁平化报告结构通常可以相当快地实施。构建一个基本的 ETL 流程，通过每晚刷新来填充此流程，您将获得可以相当有效地报告的内容。
对于更复杂的分析需求或者如果您想使用多维数据集，您可能必须硬着头皮构建适当的仓库或数据集市。
在后一种情况下，SQL Server 附带了一个名为 Report Builder 的工具（从 SQL Server 2005 开始），可以将其视为穷人的 Business Objects。这可用于提供针对报告数据库的临时报告功能。但是，由于您无法控制该工具生成的 SQL，因此如果您尝试将其与操作数据库中的原始数据结构一起使用，它的性能可能会很差。要从此类工具中获得良好的结果，往往需要一个数据库结构能够与该工具以及清理数据的 ETL 处理良好配合，从而使其表现得相当良好。
The simplest approach is to set up a server for reporting and replicate your databases onto it. Run the reports against the reporting server.
This may not be very efficient for reporting, and will probably have performance issues if you have a large reporting workload.
Depending on your reporting requirements, you may want something in between a data warehouse and a suite of reports against a copy of your operational database. Simpler, system specific flattened reporting structures can often be implemented fairly quickly. Build a basic ETL process to populate this with a nightly refresh, and you will have something that can be reported off reasonably efficiently.
For more complex analytical requirements or if you want to use cubes you may have to bite the bullet and build a proper warehouse or data mart.
In either of the latter scenarios, SQL server comes with a tool called Report Builder (from SQL Server 2005 onwards), which can be thought of as a poor man's Business Objects. This could be used to provide an ad-hoc reporting capability against a reporting database. However, as you have no control over the SQL produced by the tool, it is likely to perform poorly if you attempt to use it with the raw data structure from your operational databases. Getting good results from a tool of this sort tends to require a database structured to play nicely with the tool and ETL processing that scrubs the data so it's fairly well behaved.