使用字串作為主索引鍵
在本系列關於為關聯式資料庫選擇主索引鍵的第三部分也是最後一部分中，我們將研究使用字串資料作為主索引鍵（PK）的一些原因。回想一下，在第 1 部分部分中，我們討論了自然主索引鍵和代理主索引鍵，並考慮了什麼因素決定選擇哪一種。而第 2 部分探索了字串和數值資料類型，看看哪種更適合作為主索引鍵。現在是時候釐清事實並得出結論，字串或字母資料是否合適的主索引鍵了。
現成的主索引鍵
你的資料通常都會有一個合理的自然主索引鍵，它有通用含義，並且可能不是整數。如果是這樣的話，那麼僅僅為了要整數類型的主索引鍵而加入一個人工鍵只是多餘的。在許多資料庫開發人員的評估中，這可能會導致效能受到輕微影響，但它的重要性略低於正確性、完整性和適當的建模。
字母鍵有一個不明顯的好處是，簡短的符號字串可以簡化偵錯，因為在資料傾印（不需要額外的聯結）時人們能立即看得懂。例如，美國各州有一個唯一的字母代碼，可作為有意義的鍵。此外，各個國家或地區有自己的字母 ISO 代碼。還有無數其他的例子，例如車輛 VIN 號碼、發票 ID 等。
使用 GUID 作為主索引鍵
如果你有多個資料庫，自動遞增鍵可能會導致多餘的記錄。解決此問題的其中一種方法是使用 GUID。GUID 是「Globally Unique IDentifier」的縮寫，它是一個 16 位元組的二進位資料類型，保證在資料表、資料庫甚至伺服器之間是唯一的。
建立 GUID 的方式因不同的資料庫而有所不同，但在 SQL Server 中，NEWID() 函式的使用如下所示：
SELECT NEWID()
以下是用於建立具有 UNIQUEIDENTIFIER 資料類型的資料表的陳述式。若要為欄設定預設值，我們可以使用 default 關鍵字並將預設值設定為 NEWID() 函式傳回的值：
USE EngDB GO CREATE TABLE EnglishStudents1 ( Id UNIQUEIDENTIFIER PRIMARY KEY default NEWID(), StudentName VARCHAR (50) ) GO INSERT INTO EnglishStudents1 VALUES (default,'Shane') INSERT INTO EnglishStudents1 VALUES (default,'Jonny')
這能確保無論何時在 EngStudents1 資料表中插入新記錄，預設情況下，NEWID() 函式都會為 Id 欄產生唯一的值。在插入記錄時，我們只需將「default」指定為第一欄的值。這將在 Id 欄中插入一個預設的唯一值。
GUID 與 UUID
雖然 GUID（由 Microsoft 使用）和 UUID（由 RFC4122 定義）看起來很相似，也有相似的用途，但也有細微但非常重要的區別。首先，讓我們看看什麼是 UUID。
必須重申，UUID 是 128 位元的值，以十六進位數字表示。因為許多人認為 UUID 是以文字形式儲存。而 UUIDv4 值是隨機的，無法保證唯一性。但是，發生衝突的可能性相當小。此外，請記住，在極不可能發生 UUID 衝突的情況下，由於主索引鍵條件約束，它會被資料庫捕捉到。而且，值得高興的是 UUIDv4 已被大多數關聯式資料庫完整編製索引。
一些 Microsoft GUID 文件允許 GUID 在任何位置含有任何十六進位數字，而 RFC4122 要求為版本和變體欄位指定值。此外，GUID 應該全部大寫，而 UUID 應該「輸出為小寫字元，並且在輸入時不區分大小寫」。這可能導致程式碼庫之間的不相容。
你可以說 GUID 是 Microsoft 對 UUID 標準的實作。將它們視為用作唯一值的 16 位元組（128 位元）值。在 Microsoft 中，它們被稱為 GUID，但在其他地方，它們被稱為 UUID。
結論
在本系列關於為關聯式資料庫選擇主索引鍵的第三部分也是最後一部分中，我們得出字串或字母資料是否合適的主索引鍵的結論。答案是肯定的，但有一些需要注意的地方。你應該預料到效能會受到輕微的影響。如果這不是你考慮的因素，那麼可以選擇使用短符號字串、GUIDS 和 UUID。最後，請盡量使用固定長度的字串而不是 varchar，因為固定長度的字串在執行方面更好。
