我不知道在SQL Server中使用臨時表還是使用C＃中的DataTable作爲報表更好。以下是報告的範圍：它將被複制到一個包含大約10個工作表的工作簿中 - 每個工作表包含大約1000行和大約30列，因此它是大量數據。這裏有一些指導，但我無法找到任何關於DataTable的數據量太多的具體信息。根據https://msdn.microsoft.com/en-us/library/system.data.datatable.aspx,16M行，但我的數據集似乎是笨重的考慮到我的列數。另外，我將不得不做出多個SQL查詢來收集我的報告中的數據，或者嘗試在SQL中編寫存儲過程來收集數據。我如何找出這個窘境？何時使用臨時SQL表vs數據表
我的經驗法則是，如果它可以在數據庫服務器上處理，它可能應該。請記住，不管C＃代碼的效率如何，SQL Server最可能更快更高效，畢竟它是爲數據操作而設計的。
使用#temp表沒有什麼可恥的。他們維護統計數據，可以被索引和/或操縱。最近的一個例子是，開發人員使用cte創建了一個非常優雅的查詢，性能是12-14秒，而使用#temps的時間是1秒。
現在，一個結構謹慎的存儲過程可以生成並返回工作表的10個數據集。如果您使用的是像SpreadSheetLight這樣的產品（有很多選項可用），則只需傳遞結果並創建選項卡即可（不需要單元級循環...除非您需要或不需要）。
我還想補充一點，您可以通過讓SQL Server完成繁重工作，大幅減少觸點數量並更好地執行業務邏輯。例如，一位客戶推出了6W的風險評級，基本上是6.5。傳統報告數量必須更新，而我只需將6W添加到我的映射表中。
+1 - 就在上週，我有將一堆Common Table表達式重構爲幾個連接範圍的#temp表的經驗。我在性能上獲得了大約五十倍的因素，並減少了我忙碌的SQL Server上的爭用。能夠索引大臨時表是非常有用的。 –
@OllieJones當你得到這樣的結果時，感覺很棒。幾年前，在PC上花費6分鐘的時間在主機上花費14個小時。如果審計部門知道我在做什麼，他們會從牆上抽出我的網絡連接。 –
這裏有很多缺失的上下文 - 這個報告將如何被訪問和運行？這是否會每天都作爲腳本事件運行？
您是否考慮過SSRS？
在我看來，最好是通過在數據庫中創建Views或Stored Procedures來抽象出您的業務邏輯。存儲過程可能是要走的路，但這取決於您的具體環境。然後，您可以指定要在數據庫對象上使用的任何工具。這有幾個優點：
如果你最終有不同的版本或不同格式的報告，和你的邏輯都沒有改變，你可以在一個地方更新邏輯，而不是很多。
你的代碼更簡單和更清潔的，通常爲：
select v.col1, v.col2, v.col3 from MY_VIEW v where v.date between @startdate and @enddate
我假設你10個電子表格都將是像
摘要頁面|部門1 |部門2 | ...
所以你可以製作一個廣義的View或SP，創建一個鏈接到db對象的主電子表格，該對象從SQL中提取所有相關數據，並使用數據透視表或過濾器或其他任何你想要的，以生成發送出去的副本。
但在解決所有問題之前，我會確保SSRS不是一個選項，因爲如果你可以使用它，它會有很多功能烘焙，這會讓你的生活更輕鬆（導出到Excel，自動日期參數，計劃執行，電子郵件訂閱等）。
這是每日報告，包含過去30天的活動。你對電子表格的假設是正確的。謝謝你的想法。我會更詳細地看看SSRS。我沒有意識到它有很多集成的功能。 – Missy
「我怎麼弄出這個窘境？」 - 使用直覺，並選擇最_ _理解_和_維護_解決方案。如果結果太慢，你可以嘗試別的。最重要的部分是讓工作正確，然後擔心速度。 – Tony