報告一百萬行的最佳方法

我有兩個數據庫表，subscription和transaction，其中一個訂閱可以有很多事務。訂閱的狀態主要取決於屬於它的交易。因此，如果我想計算下一個處理日期，我會查看訂閱對象的期間字段，然後分析訂閱的交易以確定其狀態。這一切工作正常。報告一百萬行的最佳方法

我面臨的問題是該表包含超過400,000個訂閱對象和數百萬條交易記錄，因此構建訂閱的報告摘要（例如，大約十種可能的狀態中的每個狀態有多少是動態計算的）

由於所有計算每個訂閱狀態的邏輯都在c＃代碼中，因此我必須使用linq-to-sql加載其所有子事務對象的訂閱對象的整個圖表。這需要相當長的時間，也許兩分鐘左右。我正在尋找緩存，但不會提供實時結果。我只是想知道是否有一個可以解決這個問題的策略，或者可能是我的數據庫上的索引，可能會加快LINQ到SQL查詢的速度。或者如果我從一開始就把它設計的很糟糕。

謝謝。

來源

2010-01-06 Rod Johnson

由於所有的邏輯來計算每個訂閱的狀態是在 C＃代碼，我要加載整個圖表訂閱對象的與他們的孩子交易的所有

也許你不應該在客戶端加載所有這些數據，並逐行進行所有的計算。這是數據庫實際上擅長的。在服務器端進行計算，最好還是將計算結果存儲在表中，然後在報告中查看。如果您有40萬個訂閱和+ M個交易，那麼您設計的角落就是數據庫，而不是客戶。你需要在數據模型中投入你的時間和設計，客戶端在之後來到。

來源

2010-01-06 07:46:07

絕對！在客戶端上運行它可能永遠不會很快，並且保證效率低下。如果計算複雜，總會有pl-sql存儲過程或託管代碼存儲過程的選項。甚至可以直接在數據庫中運行C＃代碼進行計算。 –

創建適當的索引（沒有足夠的信息在你的問題知道這些是什麼）。假如你有好的索引，一百萬行並不是那麼大的集合來運行聯合查詢。

您可以創建一個包含計算所需狀態邏輯的視圖嗎？這大概會減少I/O，因爲不必將盡可能多的數據返回給客戶端。

來源

2010-01-06 07:29:42

一百萬行是很多加載到前端進行處理。 – cjk

@ck：你誤會了我。我並不是建議將一百萬行放到客戶端。我提到問題的加入部分。我會更新我的答案，使其更清晰。 –

數據庫問題的標準答案是，這取決於。你需要分析你的問題來確定瓶頸在哪裏。主要成本是從磁盤讀取數百萬行嗎？還是它通過網絡發送數百萬行？或者它在內存中存儲了數百萬行？

因爲每個問題都有完全不同的解決方案。例如，如果它發現你的問題是由於在實內存和虛擬內存之間交換數據造成的，那麼構建附加索引不會有幫助（除非有一個索引可以用來預過濾結果以減少行返回）。

來源

2010-01-06 07:47:14 APC

每次訪問訂閱對象時，您是否都必須重做所有計算？在某些情況下，可以將最後計算的結果存儲在對象中（或新表中），並從那裏開始計算。您可能需要將包含在計算中的最後一筆交易的編號與結果一起保存。如果在您的情況下這是可行的，您將只能將未處理的事務加載到內存中。

來源

2010-01-06 09:30:20

報告一百萬行的最佳方法

回答

相關問題