SSRS：用於條件數據集定義的模式

Question

我正在開發SSRS報告，要求用戶選擇（通過參數）檢索活數據或歷史數據。

實時數據和歷史數據的來源是SQL Server數據庫（查看實時數據;表值函數接受歷史數據的日期參數）中的單獨對象，但它們的模式 - 它們返回的列 - 是相同的，除了數據集定義之外，報告的其餘部分不需要知道它的來源是什麼。

數據集查詢從幾個數據庫對象中提取，它包含select中的連接和case語句。

根據我所描述的參數選擇（我測試過的一些參數），我可以採用幾種方法來處理來自不同來源的數據，如下所示。

主要目標是確保檢索現場數據（基本用例），其性能不會過度用邏輯存在的影響和利用，支持歷史使用情況。此外，解決方案（包括數據庫對象和rdl）的易維護性是次要但重要的因素。

1. 在數據集查詢文本中使用表達式，以使用字符串連接包含的正確源有條件地返回完整的SQL查詢文本。 優點：可以解析爲任何給定執行不受「其他」用例影響的直接查詢。報告的所有邏輯都放在報告中。 缺點：很難使用，並且對冗長的SQL有限制。
2. 在報告的代碼模塊中使用一個函數來執行與1相同的操作。優點：按照1.，但稍微好一點的設計時體驗。 缺點：按照1.，但也增加了另一層抽象，降低維護的方便性。
3. 在數據庫上實現多步驟TVF，它使用T-SQL中的邏輯處理參數並檢索正確的數據。 優點：t-SQL功能的靈活性，不涉及任何字符串構建/替換。可以從結果中選擇*並在報告的數據集查詢中應用更多報告參數。 缺點：與在線查詢相比，性能大打折扣。在rdl之外移動一些邏輯。
4. 執行與3相同的存儲過程。優點：按照3，但不方便選擇*。 缺點：按照3.
5. 實現將實況和歷史數據結合在一起的在線TVF，但是使用一個虛擬輸入參數，該虛擬輸入參數在源的where子句中添加了解析爲1 = 0的內容相關。 優點：依附於在線查詢方法，其他專業人員依據3. 缺點：感覺像一個黑客攻擊，只爲已知返回0行的查詢組件添加性能。增加查詢的複雜性。

我傾向於選擇3或4在這一點上，而是渴望聽到這將是一個首選的方法（即使這裏沒有列出），爲什麼？

Answer 1

生活與歷史有什麼區別？ 「活」數據，變化和歷史數據不？

是否無法將實時/歷史數據複製或推送到專爲報表構建的數據倉庫中？