一、類型親和性介紹

SQLite不強制數據類型約束。任何數據都可以插入任何列。你可以向一個整型列中插入任意長度的字符串，向布爾型列中插入浮點數，或者向字符型列中插入日期型值。在 Create TABLE 中所指定的數據類型不會限制在該列中插入任何數據。任何列均可接受任意長度的字符串（只有一種情況除外：標志為INTEGER PRIMARY KEY的列只能存儲64位整數， 當向這種列中插數據除整數以外的數據時，將會產生錯誤。）但SQLite確實使用聲明的列類型來指示你所期望的格式。所以，例如你向一個整型列中插入字符串時，SQLite會試圖將該字符串轉換成一個整數。如果可以轉換，它將插入該整數；否則，將插入字符串。這是一個特性，而不是一個bug。這種特性被稱為類型或列親和性(type or column affinity).

二、類型親和性總結(優點)：

1           提高和其它DBMS的兼容性，讓用戶就像是在用一般的DBMS一樣而使用它，提高了容錯能力。

2           SQLite支持的數據類型只有五種，而其它的大型DBMS支持的數據類型有幾十種，那么如果要將其它的數據轉換成SQLite下的數據就根本不能實現，所以就將它的數據類型設計為親和性的，數據類型種類少了系統實現會簡單很多，整個系統也就不會太龐大，因為如果有太多的數據類型限制的話，本身系統在實現方面也會困難些。然而，雖然它支持的類型雖然只有五種，可是實際上任何類型都支持了，這就是SQLite數據類型親和性的巧妙之處。由此我個人認為這也就是將數據類型設計成為親和性的初衷。

3           在插入數據的時候只要做一些檢查和轉換即可，實現容易

三、數據類型親和性(缺點)：

1.         在對表中數據進行統計方面如果有不一致的數據存在則運算比較混亂，其實也就是放寬政策為的是讓更多人去維護。不過它自己是有處理方法的，如果在運算時出現不同類型的數據時就忽略不計等(我認為這點也是很牽強，因為如果跳過就會得到一些不合乎人期望的結果，但我認為一般情況下，對于一列數據來說，基本上會是一致的，因為如果在很大程序上不一致的話就沒什么意義的)。

2.         還有在數據比較方面也存在同樣的問題，不過也有相應的補救措施，自己規定了比較準則：

a)         一個具有空存儲類型的值被認為小于任何值（包括另外一個具有空存儲類型的值）。

b)        一個整數值或實數值小于任何文本值和BLOB值。 當一個整數或實數和另一個整數或實數相比較的時候，則按照實際數值來比較。

c)        一個文本值小于BLOB值。當兩個文本值相比較的時候，則用C語言類庫中的memcmp()函數來比較。然而，有時候也不是這樣的，比如在下面所描述的“用戶定義的整理順序”情況下。

d)        當兩個BLOB文本被比較的時候，結果決定于memcmp()函數。