I'm CaLendarW Blog

MsSQL 內既 Identity Generator, 雖然被發現當 Table 儲存超過一百萬行時, 由 SELECT @@Identity 或者 SELECT SCOPE_IDENTITY() 會存在 Return 值錯誤既問題, 但經過呢個幾月既開發都未出現問題.

係 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 其實永遠唔會有錯, 錯就只會錯在未能正確使用它們既人, 而軟件其中一個用途就係用來避免人們使用犯錯, 所以在程式篇寫時應該以不同既設定技巧及文檔來避免人們使用錯誤, 那軟件才容易正確地被使用!!

係 Ayende 個 Blog 度見到呢個 post, 入面講述應該避免使用 identity.
(continue reading…)