我有一個關於Sql Server 2005數據庫的表。 該表的主鍵字段是一個代碼號。SQL索引 - char和int之間的差異
作爲標準,代碼必須包含正好4位數字。例如:1234,7834,...
您是否建議根據有效的選擇操作將字段類型設置爲char(4)或int或numeric(4)。 將索引表中的任何類型的表與其他任何類型不同?
我有一個關於Sql Server 2005數據庫的表。 該表的主鍵字段是一個代碼號。SQL索引 - char和int之間的差異
作爲標準,代碼必須包含正好4位數字。例如:1234,7834,...
您是否建議根據有效的選擇操作將字段類型設置爲char(4)或int或numeric(4)。 將索引表中的任何類型的表與其他任何類型不同?
由於多種原因,整數/標識列通常用於數據庫表中的主鍵。主鍵列必須是唯一的,不應該是可更新的,並且實際上應該沒有意義。這使得身份列成爲一個不錯的選擇,因爲服務器將爲您獲取下一個值,它們必須是唯一的,並且整數相對較小且可用(與GUID相比)。
一些數據庫架構師會爭辯說,其他數據類型應該用於主鍵值,而「無意義」和「不可更新」的標準可以在雙方中有說服力的爭論。無論如何,整數/標識字段非常方便,許多數據庫設計人員發現他們爲參照完整性制定了合適的關鍵值。
希望這會幫助你!
如果我沒有記錯,整數佔用的存儲空間少於字符,所以你應該使用int。 這兩個鏈接說是相同的:
http://www.eggheadcafe.com/software/aspnet/31759030/varcharschars-vs-intbigint-as-keys.aspx
http://sql-server-performance.com/Community/forums/p/16020/94489.aspx
「這取決於」
在此情況下,焦炭(4)捕獲與沒有存儲開銷正確地存儲數據(4每個字節)。當然,0001
與1
不一樣。
如果您有非數字的數字,您確實有一些處理排序規則等的開銷,但對於合理大小的數據庫應該沒有關係。並且對於4位數的代碼,您確實有行數的上限,尤其是數字(10k)。
如果你的新代碼不嚴格遞增的,那麼你得到的GUID聚集鍵
相關的頁面分割問題,如果他們是嚴格遞增,然後使用int,並添加計算列添加前導零
我主張一個SMALLINT列。僅僅因爲它是符合要求範圍的最明智的數據類型(高達65535,超過4位數)。使用檢查約束來強制執行4位限制,並使用COMPUTED列返回char(4)列。
錯誤。在這種情況下將採用相同的空間:它是char(4)而不是varchar – gbn 2011-02-28 12:17:06