係 MsSQL 入面, 新增 Record 時主要提取 Primary Key 既方法主要有 @@IDENTITY, SCOPE_IDENTY() 同 IDENT_CURRENT(‘table_name’) 三種:

@@IDENTITY
使用 @@IDENTITY 會 Return 當前 Session 任何 Table 最後生產的 Primary Key, 如果 Insert statement 運行後如果有任何 Trigger 中會 Insert 在其他 Table 的話, @@IDENTITY 就會變得不準確.

SCOPE_IDENTY()
使用 SCOPE_IDENTY() 會 Return 當前 Scope 內確實 Insert 左既 Primary Key, 就算有任何 Trigger 在背後運行都不會有任何影響, 係一個最好既選擇. 不過經由 MS Connect 入面既 Feedback 顯示, Table 被新增至一百萬行後, Return Value 有可以會籨 1 開始數起, 這問題由 MS 回應既答案中回答到已增加到它們的 Bug tracking database 中.

IDENT_CURRENT(‘table_name’)
而 IDENT_CURRENT(‘table_name’) 會 Return 指定 Table 最後生產出來的 Identity, 由於它不會理會任何 Scope 或者 Session, 當有多於一個 Scope 或者 Session 運行時便有機會出現不準確既問題.

因此, 在以上三個尋找 IDENTITY 既方法中, 並沒有一個能在任何環境下百分百準確既方法, 所以在 MsSQL 使用 Identity Generator 便會有潛在問題既可能性, 因此在 deploy 前應該對 Database 作詳細測試, 已確定當前既環境設定正確.

再者, Identity Generator 亦開始慢慢地被其他類型既方案取代, 例如 GUID, Hi/Lo or UUID 等等.

正如之前 CS != SE 文章內所講, Technology 其實永遠唔會有錯, 錯就只會錯在未能正確使用它們既人, 而軟件其中一個用途就係用來避免人們使用犯錯, 所以在程式篇寫時應該以不同既設定技巧及文檔來避免人們使用錯誤, 那軟件才容易正確地被使用!!

雖然我未測試過係咪真係有呢個情況, 但該文章中已經有五個人証明左問題既存在, 而我計算過, 如果在同一個 table 入面, 一日新增五百行數據的話, 只要五年多既時間便會去到一百萬行. 五年, 雖然我以前跟開既項目都有三年一次既資料清理, 但亦有機會有每日多於五百行或者五年不清理既情況發生.

以我在網上既搜尋下, 而家外國都開始使用 Guid, 除了同 database 有關既連結外, 我見過 M$ 既 WF Example 入面已經全部使用了 Guid, 我諗有時間既情況下都要了解一下 Guid 既好處同壞處.