2010-08-19 96 views
5

我有我所喜歡的東西創造了10000產品/顏色/尺寸組合的字典:通過密鑰查找.NET字典值的速度?

AllRecords = DB.ProductColourSizes _ 
      .ToDictionary(function(b) String.Format("{0}_{1}_{2}", _ 
      b.ProductCode, b.ColourCode, b.SizeCode)) 

所以一個例子關鍵是像「13AI_GRS_M」

我必須同步我的數據庫該公司的ERP每30分鐘一次,並且對於每種顏色/尺寸組合我都需要使用該字典來添加,編輯或刪除記錄。我希望他們提供身份證號碼。

我不知道Dictionary如何在內部工作。 .NET在基於這樣一個密鑰的基礎上找到正確的價值有多快?我應該對數據庫查詢進行排序,還是.NET有其他方法來識別密鑰?

或者我應該將它轉換成列表並使用字典來識別正確的索引?或完全是另一種方式?

我也使用靜態字典以這種方式遍佈網站的應用程序,所以學習更好的方式來做這件事會產生相當大的影響。

非常感謝,史蒂夫

+0

非常感謝您的回答。我對這個網站很陌生,所以我還沒有學會禮節,但是我意識到我問了一個問題,其中有5個人都因爲各種原因有助於指出代碼「OK」。我應該將它們標記爲有用嗎?再次感謝。 Steve – 2010-08-19 13:02:17

+0

您只能將1標記爲「已接受」。只要用你的判斷。 – 2010-08-19 13:09:50

回答

3

對於你正在做的字典是完美的。

字典中的項目的鍵檢索時間是該死的快,但最終依賴於密鑰的哈希碼功能(在你的案例string.GetHashCode())。

你很幸運,因爲.Net字符串的GetHashCode()函數非常好。 如果確實發生哈希碼衝突,.Net將調用對象上的Equals方法,從而保證唯一性。

我們有數以十萬計的物品的字典,查找時間可以忽略不計。

對數據庫中的結果集進行排序在這種情況下沒有任何好處。

希望這會有所幫助。

1

字典由仰視的東西,所以留在那。 Key類型的主要問題是它應該有一個好的(分佈良好的)哈希碼。

您可以使用ProductCode,ColourCode和SizeCode成員編寫自己的KeyClass,但您必須重載GetHashCode和Equals(及相關)成員。並且要改進System.String的GethashCode是很困難的,而且很容易出錯。

所以,不要打擾。您的密鑰字符串看起來確定

如果你想優化,首先查看你的問題。

+0

感謝您指向.NET的一個領域我不知道..別的東西來研究! – 2010-08-19 12:55:01

+1

確切地說,不要擔心性能問題,直到它成爲一個真正的問題,然後用探查器找出它,它往往不是你認爲它的地方。 – 2010-08-19 13:24:18

1

按鍵查找值非常快,使用字典似乎是絕對合適的。你創造的鑰匙在我看來也可以。預設數據庫絕對沒有意義,字典不依賴於此。

2

.NET在基於這樣的密鑰找到正確的值時有多快?

的一鍵檢索值的複雜度接近O(1)according to MSDN,所以它是非常快...

從MSDN

另外:

檢索的速度取決於關於爲TKey指定的類型的散列算法的質量。

如果使用字符串作爲鍵,你應該確定,因爲我們或許可以假設String類使用一個有效的哈希算法...

+0

托馬斯,對於迂腐道歉,但一個操作複雜性低,當然並不意味着它本質上很快。它比高複雜度的操作要快,但如果底層算法複雜,大O符號可能很低,但操作仍然很慢。還是我在說我的屁股? (我不是大O的專家) – 2010-08-19 12:25:27

+0

你是對的,複雜性並不是唯一需要考慮的事情,但非恆定的複雜性會隨着字典的增長對實際檢索速度產生重大影響。它只能這麼快,因爲它的複雜性是O(1) – 2010-08-19 12:46:37

+0

我用相對高級的語言加入了編程,並且從來不必擔心排序算法。我很高興我現在不需要。感謝您的回答。 – 2010-08-19 12:59:00

0

我用這個「模式」相當頻繁,如果你無法獲得SQL查詢(特別是在SQL CE上)足夠快的運行。

你可能想在ToLookup功能看起來也一樣,我發現它在大多數情況下,更爲方便。查找速度不受影響,它使用映射到集合的字典。

+0

ToLookup()也將在未來幫助巨大,謝謝。 – 2010-08-19 12:56:42