摘要:[SQL Server]資料庫的定序(Collation)
工作中遇到將資料庫移轉至客戶端時發現一些奇怪問題，後來查明原因後發現是定序的問題，因此查了定序相關的資料在此紀錄一下。
一般可區分為以下幾類：
Case sensitivity(CS)
簡單來說就是區分大小寫，A跟a是不同的，
如果是Case Insensitive(CI)的話A在排序或者查詢時就會被視為相同
也就是查詢A，連同a也會被查詢到。
● Accent sensitivity(AS)
代表的是腔調上的差別，a跟a、o跟o在腔調上是相同的，那查詢時是要視為相同
如果是的話，那就是Accent Insensitive(AI)，如果不是的話就視為Accent sensitive。
Kana Sensitivity(KS)
日文中的片假名(Hiragana)與平假名(Katakana)如果被視為相同
那就是Kana Insensitive(KI)，反之就是Kane sensitive.。
● Width sensitivity(WS)
當半形字與全型自被視為相同(A跟Ａ)，那就是Width Insensitive(WI)
反之就是Width sensitive。
其他
常見的有BIN與BIN2，也就是Binary Sort。這種Binary Sort會比其他Collation的效率來的好。
針對非unicode的資料，它是自動以ANSI Code來做為排序與比較的依據(CI、AI、KI、WI)，而針
對unicode資料，它則是以Unicode做為排序與比較的依據，而一旦以 Unicode作為排序依據，
Latin_1_General_BIN跟Japanese_BIN這兩種定序查詢回來的資料將會一模一樣，因為當資料都
是非unicode時，都以ANSI Code來處理；當資料都是unicode時，就以Unicode來處理，而也因為
以上特性，目前大部分的系統也習慣將資料庫的定序設定為BIN結尾的。
至於…為什麼要分這麼多類呢?
舉例來說：
資料庫設定的定序如果是『Chinese_Taiwan_Stroke_CS_AS』
表示設定的是"繁體中文"而且【區分大小寫】
那麼假設我們有一張表，名稱是「UserFile 」, 當我們在寫 SQL 句時
Select * From UserFile
Select * From userfile
上述兩者的結果是不同的，Select * From userfile 是錯誤的，UserFile 才是正確的
所以一般來說，資料庫預設都是不區分大小寫、不區分重音…等的
例如：『Chinese_Taiwan_Stroke_CI_AI』
但是，如果有一天，我們的資料庫已經設定是不區分大小寫時
而我們又希望可以針對某個欄位的資料進行大小寫區別時
可以用下述的方式做到
select * from userfile
where uid collate Chinese_Taiwan_Stroke_CS_AS = 'TestAccount';
當然除了這個方式之外，也可以針對某一張 table 去做調整
Alter TABLE tb
Alter COLUMN colname nvarchar(100) COLLATE Chinese_PRC_CI_AS --不區分大小寫
Alter TABLE tb
Alter COLUMN colname nvarchar(100) COLLATE Chinese_PRC_CS_AS --區分大小寫
參考資料：
http://ppt.cc/9VR0