|
What‘s GUID ?
GUID 是個(gè)根據(jù)網(wǎng)絡(luò)卡MAC Address 及時(shí)間等因素隨機(jī)產(chǎn)生的 128 Bits(=16 Bytes) 數(shù)字, 因?yàn)?/span> 2 的128 次方是個(gè)極大的數(shù)目, 因此發(fā)生重復(fù)的機(jī)率非常非常.... 低 (樂觀地說(shuō): 樂透中獎(jiǎng)的機(jī)率遠(yuǎn)遠(yuǎn)高于 GUID 重復(fù), 我們可以假設(shè) "不可能" 發(fā)生)!
摘錄幾個(gè)網(wǎng)絡(luò)上流傳的例子來(lái)說(shuō)明 GUID 如何地"不太可能" 發(fā)生重復(fù):
一. The probability of an accidental match is (theoretically - and I use that term guardedly) the same as throwing a set of 128 pennies,
and having them all land in the same heads/tails combination twice.
(把128 個(gè)硬幣往上拋出落地后, 所有硬幣必須出現(xiàn)兩次完全相同 "人頭" 與 "數(shù)字" 的組合)
二. 如果一臺(tái)機(jī)器每秒鐘產(chǎn)生10,000,000 個(gè)GUID, 則可以保證(機(jī)率意義上) 3,240 年不會(huì)發(fā)生重復(fù)!
三. 全世界有60 億人口, 每個(gè)人每秒分配10 億個(gè)號(hào)碼, 那么需要分配1800 億年! 反正等到地球毀滅了都不會(huì)用完的!
把 GUID 以字符串形式表達(dá)就會(huì)像 "12345678-1234-1234-1234-123456789012" (4 Bits 代表一個(gè)字符, 則有32 個(gè)字符, 加上4 條短線共有36 個(gè)字符的長(zhǎng)度)!
The challenges of designing database.
在傳統(tǒng)信息系統(tǒng)的數(shù)據(jù)庫(kù)端普遍存在幾個(gè)設(shè)計(jì)上的難題, 為了解決這些題目, 開發(fā)團(tuán)隊(duì)經(jīng)常需要付出較高代價(jià)! 這些難題包括:
一. ID (在此指概指在資料表中用來(lái)代表資料唯一性的字段) 值是否允許變更(例如: 部門編號(hào), 產(chǎn)品編號(hào), .....) ?
ID 字段總是被使用與其它資料表關(guān)聯(lián), 因此, 需要先判斷關(guān)聯(lián)是否已經(jīng)存在, 以做為 ID 字段可否變更的依據(jù)!
當(dāng) ID 字段關(guān)聯(lián)的對(duì)象數(shù)目過(guò)多時(shí), 需要在判斷上付出更多成本!
二. 由復(fù)合字段形成資料表關(guān)聯(lián)時(shí), 是否需要對(duì)更多字段進(jìn)行變更前的判斷或處理?
復(fù)合字段組成索引的典型之一是單據(jù)明細(xì) (或稱 "分錄", 或指 Detail data, 其主索引可能由單據(jù)編號(hào)及明細(xì)序號(hào)(流水號(hào)) 組成)!
當(dāng)某筆明細(xì)資料前方插入或是刪除另一筆明細(xì)時(shí), 原有的明細(xì)序號(hào)是否需要變更? 不變更時(shí)明細(xì)序號(hào)是否連號(hào)且不重復(fù)?
變更后是否會(huì)破壞原有與其它資料的關(guān)聯(lián)?
這可能是個(gè)取舍兩難的問題: 由于明細(xì)資料前方插入或刪除另一筆明細(xì)資料時(shí), 在后方的所有明細(xì)資料的序號(hào) "被迫" 遞增或遞減
(就像棒球在滿壘狀況下, 觸身球會(huì)造成三壘跑者被 "強(qiáng)迫" 擠回本壘得分), 則索引值會(huì)發(fā)生變化, 而系于該索引上的關(guān)聯(lián)就會(huì)錯(cuò)亂!
三. 無(wú) ID 或主索引字段的資料, 能否與其它資料建立關(guān)聯(lián)?
在自然情況下有些資料并不需要 ID 字段 (或是 ID 字段值并無(wú)實(shí)質(zhì)意義), 例如:
1. 每天例行發(fā)出的提醒信息可能并不需要 ID 值, 但是, 當(dāng)使用者從清單中選擇一筆資料時(shí), 系統(tǒng)如何明確地找到被指定的提醒明細(xì)呢?
2. 展開MPS 是一個(gè)批次作業(yè), 其過(guò)程中會(huì)有許多的記錄臨時(shí)被產(chǎn)生或是合并!
在每一筆過(guò)渡記錄產(chǎn)生時(shí), 并不需要具有編碼規(guī)則的 ID 字段, 但是在整合同料號(hào)同時(shí)段的生產(chǎn)需求時(shí), 如何能夠正確地標(biāo)記已被合并的數(shù)據(jù)呢?
歸納以上的難題, 我們可以發(fā)現(xiàn)需求的核心就是: 能否為數(shù)據(jù)庫(kù)里的所有記錄, 賦予一個(gè): (1)簡(jiǎn)單, (2)獨(dú)一無(wú)二, (3)不會(huì)改變的"身份識(shí)別"?
How does GUID change the world ?
GUID 的唯一性完全滿足我們的需求, 因此, 我們可以一個(gè) GUID 字段做為代理鍵, 以取代自然鍵 (通常為資料表中"ID" 字段, 或是復(fù)合字段組成的主要索引), 并化解實(shí)務(wù)上遭遇的問題:
一. GUID 隔離了自然鍵以及關(guān)聯(lián)的資料表:
自然鍵是可以被檢視的, 若自然鍵為ForeignKey 且有對(duì)應(yīng)的關(guān)聯(lián)資料, 為了保持資料的一致性, 自然鍵值不應(yīng)被異動(dòng)或刪除!
這樣的保護(hù)控制大都需要額外的程序代碼去處理!
代理鍵通常并不具字面上的意涵(例如: GUID), 因此, 在檢視資料時(shí)并不會(huì)顯現(xiàn)該字段, 所以代理鍵在產(chǎn)生后, 該值并無(wú)機(jī)會(huì)發(fā)生改變!
以代理鍵替代自然鍵成為資料表關(guān)聯(lián)的主角, 自然鍵相對(duì)地成為類似"備忘" 性質(zhì)的字段!
由于代理鍵被隱藏而不會(huì)被變更, 不論自然鍵如何修改, 根源于代理鍵所形成的數(shù)據(jù)關(guān)聯(lián)永遠(yuǎn)穩(wěn)定地存在!
二. GUID 替代復(fù)合字段的自然主鍵:
當(dāng)自然主鍵是由多個(gè)字段組合而成時(shí), 要撰寫資料關(guān)聯(lián)的SQL command 就顯得有點(diǎn)煩人! 運(yùn)用 GUID 字段進(jìn)行關(guān)聯(lián), 可以輕易地使 SQL 化繁為簡(jiǎn)!
另外, 當(dāng)自然鍵由復(fù)合字段組成時(shí), 有更多字段被同時(shí)使用于資料關(guān)聯(lián), 相對(duì)地, 需要對(duì)字段組合進(jìn)行更多判斷或是限制變更!
這樣的控制需要付出偏高的代價(jià), 實(shí)務(wù)上, 也不盡然可以進(jìn)行控制, 例如: 因?yàn)槠渌鼏螕?jù)明細(xì)的增減, 會(huì) "強(qiáng)迫" 部份單據(jù)明細(xì)自然鍵里的序號(hào)字段遞增/ 遞減!
若以 GUID 做為代理鍵擔(dān)任資料表的關(guān)聯(lián)角色, 單據(jù)明細(xì)的 "序號(hào)" 字段因不涉及關(guān)聯(lián), 即可依據(jù)實(shí)務(wù)上的需求被變更, 并不需要額外的判斷或控制!
三. 無(wú)自然鍵的資料表由 GUID 代理主鍵的功能:
在無(wú)自然主鍵的資料表建立 GUID 代理鍵后, 每一筆記錄即刻具備可供識(shí)別 "身份" 的信息!
即使后來(lái)因?yàn)樾枨笞兏仨毚嫒≡撡Y料表中特定的記錄時(shí), GUID 代理鍵的存在足以滿足這類的變動(dòng) (類似 "防震" 效果)!
The actual usage of GUID
一. 在多對(duì)多的關(guān)聯(lián)里替代復(fù)合字段以簡(jiǎn)化對(duì)應(yīng):
如: 傳票分錄的立沖 (傳票明細(xì)多對(duì)多立沖), 借還款的沖銷 (多對(duì)多沖銷), ..... 等, 可由 GUID 代理鍵進(jìn)行關(guān)聯(lián), 即可依 GUID 合并后統(tǒng)計(jì)沖銷金額!
二. 在臨時(shí)產(chǎn)生的資料中提供精確的識(shí)別:
如: 有些復(fù)雜報(bào)表需要額外統(tǒng)計(jì)或運(yùn)算, 當(dāng)這些運(yùn)算不需以程序代碼循環(huán)處理, 即可以SQL command 直接在該報(bào)表的暫存數(shù)據(jù)表批次運(yùn)算
(其實(shí)多數(shù)報(bào)表均為如此)!
當(dāng)多人同時(shí)檢視相同報(bào)表 (檢視條件并不相同), 即可運(yùn)用 GUID 做為該暫存資料表中的識(shí)別! 每個(gè)使用者每次檢視報(bào)表即為一個(gè) Task (TaskGUID),
報(bào)表運(yùn)算后只回傳 TaskGUID 相符的數(shù)據(jù)!
幾種高階的開發(fā)語(yǔ)言 (包括: .NET, VB, Delphi, PowerBuilder, ....) 均已包裝或是實(shí)現(xiàn)呼叫 Windows API 以產(chǎn)生 GUID 字符串的方法了, 所以這個(gè) GUID 值可以由程序代碼自行產(chǎn)生!
Microsoft SQLServer 也提供了取得 GUID 字符串的函式 NewID; 還有未公開的 Stored procedure: sp_MSforeachtable, 它可以對(duì)數(shù)據(jù)庫(kù)中所有的資料表進(jìn)行統(tǒng)一的操作!
結(jié)合 sp_MSforeachtable 與 NewID, 我們可以在幾秒鐘內(nèi)對(duì)所有資料表統(tǒng)一添加名為 "GUID" 的字段(實(shí)例如下), 開始讓 GUID 做為資料搜尋或關(guān)聯(lián)的根據(jù)!
/* 先指定要添加 GUID 字段的數(shù)據(jù)庫(kù)后, 直接執(zhí)行下列語(yǔ)法 */
sp_MSforeachtable @command1=‘ALTER TABLE ? ADD [GUID] VarChar(36) NOT NULL
Constraint [?_DF_GUID] DEFAULT (newid())
Constraint [?_IX_GUID] UNIQUE NonClustered‘
What‘s matter with GUID?
由于做為索引字段(不論是Clustered Index/ Nonclustered Index) 的GUID 長(zhǎng)度為36 Bytes, 相較于其它的自然鍵或自動(dòng)編號(hào)(整數(shù)) 均顯得過(guò)長(zhǎng), 使得索引頁(yè)可容納的信息較少, 必須搜尋較多的索引頁(yè)次才能查詢所需要的結(jié)果, 因此, 各個(gè)網(wǎng)絡(luò)討論區(qū)對(duì)于 GUID 在效能方面的表現(xiàn)是頗有質(zhì)疑的!
不過(guò), 數(shù)據(jù)庫(kù)系統(tǒng)的效能包括許多因素, 包括: 系統(tǒng)設(shè)計(jì)理念, 資料表切割, 索引設(shè)定, SQL command 撰寫, 內(nèi)存配置, IO 設(shè)備, ..... 等 (排行愈前者影響愈大), 效能調(diào)整需要全面的協(xié)調(diào)與改善, GUID 不會(huì)是運(yùn)行效能的瓶頸肇因!
市場(chǎng)上已存在著全面運(yùn)用 GUID 代理鍵的商用軟件, 被中小企業(yè)廣泛采用的 Microsoft.SharePoint 系統(tǒng)也是如此!
由于運(yùn)用 GUID 做為代理鍵, 許多因?yàn)樽匀绘I直接關(guān)聯(lián)的難題會(huì)因?yàn)?/span> GUID 的隔離而被優(yōu)雅地化解, 原自然鍵上的復(fù)雜控制均可省略, 資料表之間的關(guān)聯(lián)變得單純, 數(shù)據(jù)庫(kù)系統(tǒng)的運(yùn)作也更穩(wěn)定!
|
