【问题标题】:Reporting System Architecture报告系统架构
【发布时间】:2010-01-13 06:03:56
【问题描述】:

我们已经构建了企业/LOB 软件,例如,在 .NET 3.5 和 SQL Server 2008 中管理订单、客户、库存等。

我们进行各种报告,例如

  1. 传统报告(SQL 查询)
  2. 仪表板(带有图表、列表等)
  3. 警报(例如,如果订单被取消,请向主管发送电子邮件)

现在,我们正在直接查询我们的运营数据库。我们有时会遇到性能问题,我想知道这是否可以通过优化我们查询数据库的方式或更多涉及的方式来解决,例如使用 SQL Report Server 或在另一台服务器上复制数据库并针对它进行查询。

大家有什么建议吗?或者我可以阅读的任何资源?

非常感谢您的帮助。

谢谢。

【问题讨论】:

    标签: .net sql-server reporting-services


    【解决方案1】:

    首先,使用 Reporting Services 对您没有多大帮助,因为您最终会对同一个数据库执行相同的查询,只有渲染引擎会改变,它可以通过 caching 报告提供一些帮助尽管。这是否能解决您的问题取决于您的负载和问题所在(低效查询仍然会很慢。)

    优化查询是我尝试的第一个尝试,因为它永远不会受到伤害,而且只能是一个很好的练习。

    如果这还不够,我会考虑使用只读数据库副本进行报告,或者如果您的报告可以从数据仓库方法中受益,则构建一个 OLAP 多维数据集。要使最后一个工作,您必须安装 Analysis Services。

    【讨论】:

    • 感谢 Vinko 提供的信息。您能否评论一下只读副本与 OLAP 多维数据集?每种方法的好处和坏处是什么?您会在哪种情况下使用每种方法?
    • 只读副本对于事务性报告很有用,其中数据不断变化,无需转换即可使用(也就是说,它按原样有用)。另一方面,OLAP 对于获取数据的不同视图(转换)以及事务数据必须在代码(或 SQL)中进行大量处理才能有用,或者您需要向数据添加更多维度的地方很有用。使用的数据(时间是典型的例子。)在这里阅读更多关于 OLAP 的信息:wikipedia.org/wiki/OLAP
    【解决方案2】:

    SSRS 实际上可以提供帮助,因为它具有对缓存结果和报告的内置支持。见Report Caching in Reporting Services

    【讨论】:

    • 好点。虽然这并不意味着不应该优化查询。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2011-10-05
    • 2010-12-17
    • 1970-01-01
    • 2022-08-20
    • 2010-09-06
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多