使用散列作爲主鍵？

我有一個要求來存儲多臺計算機的服務列表。我想我會創建一個表來保存所有可能的表的列表，一張表用於所有可能的計算機，然後是一張表來將服務鏈接到計算機。使用散列作爲主鍵？

我想保持完整的服務列表的唯一性，我可以使用可執行文件的哈希作爲服務的主鍵，但我不確定是否會有任何缺點（請注意，散列僅用於識別，不適用於任何類型的安全目的）。我想的不是使用二進制字段作爲主鍵/外鍵，而是將該值存儲爲base 64編碼的sha512，並使用nvarchar(88)。一些與此類似：

CREATE TABLE Services 
(
    ServiceHash nvarchar(88) NOT NULL, 
    ServiceName nvarchar(256) NOT NULL, 
    ServiceDescription nvarchar(256), 
    PRIMARY KEY (ServiceHash) 
)

是否有此解決方案的任何固有的問題？（我將使用SQL 2008數據庫並通常通過C＃.Net訪問它）。

來源

2012-07-03 Kyle

哈希不保證是唯一的。只需使用一個GUID – Chris

'Nvarchar（88）' - 這是一個潛在的非常寬（可變長度）的密鑰;如果你使用它作爲你桌面上的集羣密鑰（默認情況下是PK），那麼你將不會對該表的表現感到滿意！ –

@marc_s變得更好。由於atat是散列中的base64編碼數字，因此varchar的N部分從未被定義使用，所以您將存儲空間加倍完全無用。好點，我忽略了這一點。 – TomTom

問題是每個定義的散列都不是唯一的。碰撞不太可能，但這是可能的。因此，您不能僅使用散列，這意味着整個散列ID是一個死衚衕。

使用正常的ID字段，在ServiceName上使用索引的唯一約束。

來源

2012-07-03 13:42:05 TomTom

從性能角度來看，擁有非增量主鍵會導致您的聚簇索引相當快速地分段。

我建議之一：

使用的INT或BIGINT替代PK，通過自動遞增。
使用sequential GUID作爲PK。索引編制速度不如INT快，但增量快，因此碎片時間短。

然後，您可以在其他列上使用非聚簇索引，包括存儲散列的索引。作爲VARCHAR，您還可以對其進行全文索引，然後在查找特定散列時進行精確匹配。

但是，如果可能的話，請使用數值散列，並在其上創建一個非聚集索引。

當然，請考慮下面提到的@TomTom。

來源

2012-07-03 13:45:07

使用散列作爲主鍵？

回答

相關問題