是否有提高报告生成速度的一般指导原则？

Question

是的，您需要做的很多事情不仅针对您使用的供应商，而且针对您正在创建的特定报告。但是，大多数报告都有适用的一般规则。

以下是我从主要供应商处找到的最佳链接。

供应商最佳做法

1. BIRT Best Practices（更多为什么你需要一个3天的课程来学习所有的 他们）
2. Crystal Reports Best Practices
3. Microsoft Sql Server Best Practices
4. Oracle B.I. Publisher Best Practices
5. Windward Reports Best Practices
6. General tips on designing a report

Answer 1

来自：Turbo-charge Your Report Speed – General Rules & Guidelines

作为Windward的CTO（和创作者）的一个优点是我几乎看到了什么＆amp;人们可以用报告，文档生成，仪表板等完成所有事情。由于Windward是自由形式的，我可能会看到比竞争对手更多的变化。从这个角度来看，我已经学到了一些基本的做法和注意事项，我认为这些做法和做法都适用于所有报道，docgen和＆amp;仪表板系统。

报告设计

1. 如果没有其他条件遵循此规则 - 请不要与报表设计师对抗。如果您使用假设带状报告的系统（Crystal，SSRS等），则创建带状报告。如果你试图在交叉目的下工作，你会发现它很难，令人沮丧，而最终的设计将是一系列的妥协。
2. 使用适当的方法。例如，使用Windward，您可以使用Word或Excel（或PowerPoint）进行设计。然而，我们有客户使用Word表格设计电子表格，并使用Excel中的几个表格设计文档。当他们从Word切换到Excel（反之亦然）时，那些困难的东西变得非常容易。
3. 了解并接受设计师的限制。例如，SSRS将子报告视为单独的报告，因此您无法在报告的上下文中呈现子报告。在构建模板结构时需要牢记这一点。
4. K.I.S.S。 - 保持简单（愚蠢）。我遇到过很多案例，在深入了解客户所遇到的问题时，核心问题是他们不清楚他们试图了解哪些信息，以及哪些数据代表了这些信息。 Try to be very clear on what you are presenting and what that information is。
   1. 饼图是邪恶的。

系统架构

1. 如果报告引擎在应用程序的上下文中运行，请为多个同时报告请求创建多个线程。报告生成往往会受到严重的I / O限制，因此您可以获得巨大的成功。我们的经验法则是线程数是系统核心数的两倍。 （并且超线程计算为此度量的不同核心。）
2. 购买足够的内存。如果您要生成10,000页报告，则需要超过½Gig。
3. 注意您对网络I / O的依赖。如果您通过网络提取图像或子报告，则该网络连接很容易成为您速度的门控因素。
4. 在负载下针对您的系统运行探查器。一般来说，最大的打击时间将是一个惊喜，通常你可以解决。

数据访问

1. 只需提取您需要的数据。 SQL select几乎不应该以“select * ...”开头，因为你很少需要每一列。仅选择需要在报告中显示的列。
   1. 您无需选择在联接中使用的列，按顺序或按标准选择（我会看到很多）。您可以在选择中使用列而不返回它们。
2. 对于复杂连接，如果可能，请将其作为视图添加到数据库中。如果无法完成，请将其创建为数据集。优化数据库以将复杂联接作为视图处理，并且大多数报告系统将数据集构建为临时视图。
3. 对于XML数据，请最小化XML数据集的大小。使用XPath或XQuery要求将整个XML结构作为DOM或XPath优化结构读入内存。较大的数据集意味着更大的内存使用量和更多要遍历查询的节点。 （对于Windward，我们发现几百兆字节通常很快，但是当你进入千兆字节时它开始产生影响。）
4. 不要两次提取数据。如果要遍历数据行（或XML中的节点），则每次迭代都会在主迭代器中为该行/节点提取所有需要的数据，然后直接访问它。在迭代循环中有一个select语句应该很少见。
5. 对于SQL，请确保为连接使用的所有列以及sort或where子句的关键部分都已编制索引。 （大多数人都会说全部，磁盘空间也很便宜。但是如果你总是按last_name排序，那么first_name然后必须索引last_name，如果空间允许，应该将first_name编入索引。生命就是权衡。）
6. 对于XML，创建一个包含数据类型的模式。这避免了歧义，XPath / XQuery不仅需要做出假设，而且还必须做额外的处理来确定它们应该假设什么。