MD5哈希作爲人造鍵

-1

我看到很多應用程序使用散列作爲替代鍵而不是普通整數。我無法看到這種設計有什麼好的理由。MD5哈希作爲人造鍵

鑑於大多數UUID實現只是散列時間戳，爲什麼很多數據庫設計人員將它們選擇爲應用程序範圍內的代理鍵？

2010-11-16 Paulo Scardine

很好的回答在這裏：[GUID/UUID數據庫鍵的優點和缺點]（http://stackoverflow.com/questions/45399/advantages-and-disadvantages-of-guid-uuid-database-keys） – 2010-11-16 13:11:27

由0xA3提供的鏈接談論真正的人工代理（GUID）。我的解釋是，這個線程實際上是關於使用MD5而不是系統生成的代理的數據庫中有意義值的散列。那是我在寫作答案時的假設。 – sqlvogel 2010-11-16 14:32:37

@dportas：你的回答中的情況確實是一個很好的例子，其中使用散列是有意義的;現在我正在從SugarCRM分支中查看數據庫模式，每個表都有UUID樣式的鍵，這種設計的原因令我好奇。 – 2010-11-16 16:27:30

如果應用程序的數據後端由多個分佈式數據庫組成，則使用遞增的整數ID可能會導致重複的值。保證UUID不僅在應用程序內而且在其外部是唯一的（這可能在與外部數據連接時很有用）。

在系統中爲不同的數據庫使用不同的id種子可以解決整數的唯一性問題，但管理這種方法會更困難。

來源

2010-11-16 13:02:38

跨服務器的唯一性？在這種情況下，使用普通整數將效果不佳。

來源

2010-11-16 13:01:56 paulbailey

哈希允許在潛在的大數據值之間進行更有效的比較 - 例如在連接中。即HASH（LargeObjectA）= HASH（LargeObjectB）的比較。例如，如果散列值是文檔管理系統的表格中的文檔，則比文檔比較散列可能更有效。

大多數DBMS對密鑰的存儲大小都有限制，所以哈希可能是實現更大密鑰的一種替代解決方法。

通過將數據拆分爲均勻分佈在數據集中的邏輯分區，還可以使用散列優化存儲。

來源

2010-11-16 14:28:30 sqlvogel

MD5哈希作爲人造鍵

回答

相關問題