是否有任何提高報告生成速度的一般準則？

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（和創建者）是我見過任何事情&一切有人能報告，文檔生成，儀表板等做， Windward是自由形式的，我可能在競爭對手中看到比我的對手更多的變化。從這個角度來看，我已經瞭解到我認爲在所有報告，docgen，&儀表板系統中都有的一些基本做法和不應做的事情。

報表設計

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 * ...」開頭，因爲你很少需要每一列。只選擇您需要在報告中顯示的列。
   1. 您不需要選擇您在連接中使用的列，順序依據或條件（我看到很多）。您可以在select中使用列而不返回它們。
2. 對於複雜的連接，如果可能的話，將其作爲視圖添加到數據庫中。如果無法完成，請將其創建爲數據集。數據庫經過優化以處理複雜的連接作爲視圖，大多數報告系統會將數據集構建爲臨時視圖。
3. 對於XML數據，請儘量減少XML數據集的大小。使用XPath或XQuery需要將整個XML結構作爲DOM或XPath優化結構讀入內存。較大的數據集意味着更大的內存使用量和更多的節點遍歷查詢。 （對於Windward，我們發現幾百兆字節通常很快，但是當你達到千兆字節時，它開始產生影響。）
4. 不要拉數據兩次。如果您要遍歷數據行（或XML中的節點），那麼對於每次迭代，在主迭代器中爲該行/節點提取所有需要的數據，然後直接訪問它。在迭代循環中有一個select語句應該很少見。
5. 對於SQL，確保用於連接的所有列以及排序或where子句的關鍵部分都編入索引。 （大多數人會說全部，並且磁盤空間很便宜，但是如果你總是按last_name，first_name排序，那麼當last_name必須被索引時，如果空間允許，應該對first_name進行索引，生命是折衷的）
6. 對於XML創建數據類型的模式。這避免了XPath/XQuery不僅需要作出假設的不明確性，而且他們必須做額外的處理來確定他們應該假定的。