我們使用一個基本實體，它具有版本（NHibernate需要的日期時間）和guid（作爲鍵）等屬性。使用Int64而不是int來代替int（C＃）
它也有一個Id（int）字段有兩個函數。首先要關聯遺留應用程序密鑰（如果有的話）。其次，作爲一個簡寫代碼：例如有時創建文件基於這些看起來醜陋和長期使用我們的GUID鍵。我的問題不是關於基礎實體的利弊，而是關於將這個Id提升到Int64的問題？
它不會影響它在我們的MS SQL Server數據庫中的存儲方式。我們的緩存和內存會有更多的費用嗎？這真的是一個擔心嗎？
我有興趣聽到除性能以外的其他缺點。也考慮到這些價值觀可能會通過網絡服務及時暴露給第三方。
另一種方法是處理大整數的異常，因爲它們在派生實體中出現並實現它們。其缺點是需要在代碼中完成，當我們發現生產大整數時的某些情況時，我們會做什麼？當然會有輸入驗證來阻止實際錯誤，但它可能會限制擴展數據。
那麼，int64使用8字節的內存存儲，而int使用4字節......但是，你已經指出了大多數缺點。當然，在許多系統上執行的計算也會比較慢（64位系統運行在64位模式下可以在64位上執行與32位一樣快的操作，但32位系統需要執行額外的工作，這意味着需要增加兩個64位位數由兩個32位加上一些額外的代碼執行 - 其他數學運算將同樣分解爲32位操作）。但是，除非你存儲了數百萬個這樣的數字並且執行了大量的操作，否則我懷疑你會看到任何性能差異，不管是在CPU時間還是在內存中。
可移植性...雖然如果你打算使用便攜式，C＃並不是真正的通用語言，那麼對於你的觀點來說這可能是沒有意義的？
如果你的應用程序在64位CPU上運行，那麼可能沒有太大的區別。
在一個32位的CPU上，一個64位的整數對於執行計算來說會佔用更多的處理器資源。
還有明顯的內存使用。
只有你可以回答你的緩存空間有多少關注。如果這是緩存密鑰，並且你有一些巨大的值作爲值，那麼向密鑰添加額外的4個字節不會產生太大的影響。如果全部您存儲的是ID，那麼顯然它將具有更重要的顯着效果。
此刻存儲您的ID需要多少內存？
可移植性問題在哪裏？我不是說沒有一個人，只是對它可能在哪裏感到困惑。我不能輕易想到一個沒有64位整數類型的通用平臺。 – 2008-10-28 11:23:49
我想說，如果所有平臺都基於公共語言規範實現它們的類型，那就不應該成爲問題。或者我錯了？ – lowglider 2008-10-28 12:14:16