2009-07-01 86 views
1

我需要相對快速地確定用戶計算機上的一組文件是否已由我的應用程序處理過。所討論的應用程序將用戶的文件上傳到服務器,如果這些文件之前已經上傳,則會跳過上傳。到目前爲止,我的計劃是對文件進行散列處理,然後將結果和上傳到服務器的標識符一起存儲。我想我會遇到的問題是,由於哈希的長度,存儲這些數據可能會變得非常麻煩。我預計目前大約有30-40個文件,但這可能會翻番或(假設)甚至三倍。快速確定一組文件在C#中是否相同?

這將有可能存儲使用一個字典,哈希作爲關鍵和服務器信息作爲價值?然後我會將該Dictionary存儲在App的Properties.Settings.Default對象中。用這個系統存儲是否可行?還是我會遇到某種問題?請注意,由於應用程序的性質,有兩個用戶擁有相同數據集的機會有沒有,所以我不需要比較用戶之間的上傳。另外,對於這種類型的操作,性能會如何?預計用戶至少將擁有1 GB RAM的Pentium-M 1.5 GHz處理器。

回答

2

我可能不會把字典放到app.config文件中,雖然我猜你可以,這取決於服務器信息。我可能只是將它自己放在一個文本文件中,除非您發現由於某種原因而成爲更多問題。感覺好像是更多的數據對於的應用比配置的應用程序。

性能不應該成爲一個問題 - 字典的設計仍然有效,其中百萬條目,更不用說數十或數百條了。

+0

我其實不會將它存儲在app.config文件中,而是存儲在user.config文件中。雖然你的觀點很好,但我可能會把它分開。不需要user.config文件來氣球!至於字典,我想知道是否有一個長度的大小關鍵它可以存儲?如果我只是將這些哈希連接起來,那會起作用嗎?對於性能,我擔心文件的哈希。這些用戶的筆記本電腦能夠在合理的時間內完成此操作嗎? – jasonh 2009-07-01 18:29:02

+0

沒有必要開始連接哈希 - 每個哈希將相當短,字典無論如何可以應付長鍵。是的,筆記本電腦應該絕對適用於哈希 - 大多數哈希計算相對便宜;大部分時間將被讀取文件。 – 2009-07-01 18:46:29

+0

我想我錯過了一條重要的信息。這些文件集合在一起,因此,爲每個文件創建一個字典條目是沒有意義的,是嗎? – jasonh 2009-07-01 18:55:08

1

在談到獲得哈希值,我想我會提到這一點...

使用哈希值是好的,只要你沒有失敗每次都得到相同的結果。我讀過的地方.GetHashCode()在不同版本的.NET之間是不一樣的,所以如果你打算把散列保存在持久狀態,我會避免使用.GetHashCode()。如果全部一次完成,那麼.GetHashCode()對於比較事情是否相同是比較理想的。

如果你需要保存哈希值,那麼在.NET中有可用的哈希類。我承認不是這方面的專家,但我認爲SHA1有一個哈希方法。

0

爲什麼不比較File Modified DateTime呢?爲此,您需要將修改日期保存在服務器上。

相關問題