報表解決方案

Question

我正在徵求關於報表解決方案的建議

我們開發了很多內部項目（.net和sql server）。對於較大的數據庫，我們使用業務對象並構建用於報告的Universe，以便分析人員或報告編寫人員可以構建報告，開發人員不需要參與。

我們的許多項目都包含重要數據，但數量不夠大，無法向構建於其上的Universe和數據倉庫發出警告。我們仍然需要根據這些數據構建報告，但我們不希望報告實時數據庫，因爲這可能會影響應用程序的性能。對於我們的一些項目，我們每晚進行備份/恢復，有效地複製數據庫，然後將副本用作報告數據庫。沒有很多報告經驗，我想知道人們已經實施了哪些其他解決方案。

Answer 1

在這種情況下，我們將OLTP數據庫中的transactional replication設置爲用於報告目的的輔助數據庫。

Answer 2

如果您正在運行2008，則可以使用資源調控器來限制報告用戶在生產數據庫服務器上的cpu和內存使用情況。最好的方案是有一個專用的報告服務器和數據庫，但這可以工作。

Answer 3

最簡單的方法是設置一個服務器來報告並將數據庫複製到其上。針對報告服務器運行報告。

這可能不是非常有效的報告，並且如果報告工作量很大，可能會出現性能問題。

根據您的報告要求，您可能需要在數據倉庫和報告套件之間針對您的運營數據庫的副本進行操作。更簡單，系統特定的扁平化報告結構通常可以相當快地實施。構建一個基本的ETL過程，以便每晚刷新一次，並且您將擁有可合理有效地報告的內容。

對於更復雜的分析需求，或者如果您想要使用立方體，您可能必須咬緊牙關，建立一個合適的倉庫或數據集市。

在後面的任何一種情況下，SQL Server都附帶一個名爲Report Builder（從SQL Server 2005起）的工具，它可以被認爲是一個窮人的Business Objects。這可以用來針對報告數據庫提供臨時報告功能。但是，由於您無法控制該工具生成的SQL，因此如果您嘗試將它與來自操作數據庫的原始數據結構一起使用，則它可能執行得不好。從這種工具中獲得好的結果往往需要一個結構良好的數據庫來處理清理數據的工具和ETL處理，因此它的表現相當好。