大部分?jǐn)?shù)據(jù)庫在進(jìn)行字符串比較的時(shí)候，對(duì)大小寫是不敏感的。但是，最近使用SQLite的時(shí)候，卻發(fā)現(xiàn)它的情況恰好相反。
假設(shè)表User的結(jié)構(gòu)和值如下：
執(zhí)行下面的SQL語句：
復(fù)制代碼 代碼如下:
SELECT * FROM [User] WHERE UserName = 'user1'
結(jié)果是沒有找到任何記錄。明顯地，SQLite在進(jìn)行字符串比較的時(shí)候，默認(rèn)對(duì)大小寫是敏感的。這會(huì)對(duì)應(yīng)用程序造成不良的影響。比如，用戶在輸入用戶名的時(shí)候必須嚴(yán)格按照大小寫輸入，這是一種很不好的用戶體驗(yàn)；用戶表中可能同時(shí)存在 user 和 USER 兩個(gè)用戶，容易造成混淆。
由于SQLite是近年來才興起的數(shù)據(jù)庫，中文資料少得很。Google了一些英文資料，終于找到了三種解決方案：
方案一：使用大小寫轉(zhuǎn)換函數(shù)LOWER、UPPER
復(fù)制代碼 代碼如下:
SELECT * FROM [User] WHERE LOWER(UserName) = 'user1'
方案二：在進(jìn)行比較時(shí)強(qiáng)制聲明不區(qū)分大小寫
復(fù)制代碼 代碼如下:
SELECT * FROM [User] WHERE UserName = 'user1' COLLATE NOCASE
方案三：創(chuàng)建表時(shí)聲明該字段不區(qū)分大小寫
復(fù)制代碼 代碼如下:
CREATE TABLE [User] ( [UserName] NVARCHAR(20) COLLATE NOCASE );
如果在任何情況下都不需要對(duì)大小寫敏感，方案三是最好的解決方案；如果只是少量查詢對(duì)大小寫不敏感，可以用方案二。而方案一由于用到了函數(shù)，可能有額外的性能損失，不推薦使用。
