SQLite數(shù)據(jù)庫的類型親和性分析
一、類型親和性介紹
SQLite不強制數(shù)據(jù)類型約束。任何數(shù)據(jù)都可以插入任何列。你可以向一個整型列中插入任意長度的字符串，向布爾型列中插入浮點數(shù)，或者向字符型列中插入日期型值。在 Create TABLE 中所指定的數(shù)據(jù)類型不會限制在該列中插入任何數(shù)據(jù)。任何列均可接受任意長度的字符串（只有一種情況除外：標志為INTEGER PRIMARY KEY的列只能存儲64位整數(shù)， 當向這種列中插數(shù)據(jù)除整數(shù)以外的數(shù)據(jù)時，將會產(chǎn)生錯誤。）但SQLite確實使用聲明的列類型來指示你所期望的格式。所以，例如你向一個整型列中插入字符串時，SQLite會試圖將該字符串轉換成一個整數(shù)。如果可以轉換，它將插入該整數(shù)；否則，將插入字符串。這是一個特性，而不是一個bug。這種特性被稱為類型或列親和性(type or column affinity).
二、類型親和性總結(優(yōu)點)：
1、提高和其它DBMS的兼容性，讓用戶就像是在用一般的DBMS一樣而使用它，提高了容錯能力。
2、SQLite支持的數(shù)據(jù)類型只有五種，而其它的大型DBMS支持的數(shù)據(jù)類型有幾十種，那么如果要將其它的數(shù)據(jù)轉換成SQLite下的數(shù)據(jù)就根本不能實現(xiàn)，所以就將它的數(shù)據(jù)類型設計為親和性的，數(shù)據(jù)類型種類少了系統(tǒng)實現(xiàn)會簡單很多，整個系統(tǒng)也就不會太龐大，因為如果有太多的數(shù)據(jù)類型限制的話，本身系統(tǒng)在實現(xiàn)方面也會困難些。然而，雖然它支持的類型雖然只有五種，可是實際上任何類型都支持了，這就是SQLite數(shù)據(jù)類型親和性的巧妙之處。由此我個人認為這也就是將數(shù)據(jù)類型設計成為親和性的初衷。
3、在插入數(shù)據(jù)的時候只要做一些檢查和轉換即可，實現(xiàn)容易
三、數(shù)據(jù)類型親和性(缺點)：
1、在對表中數(shù)據(jù)進行統(tǒng)計方面如果有不一致的數(shù)據(jù)存在則運算比較混亂，其實也就是放寬政策為的是讓更多人去維護。不過它自己是有處理方法的，如果在運算時出現(xiàn)不同類型的數(shù)據(jù)時就忽略不計等(我認為這點也是很牽強，因為如果跳過就會得到一些不合乎人期望的結果，但我認為一般情況下，對于一列數(shù)據(jù)來說，基本上會是一致的，因為如果在很大程序上不一致的話就沒什么意義的)。
2、還有在數(shù)據(jù)比較方面也存在同樣的問題，不過也有相應的補救措施，自己規(guī)定了比較準則：
a)一個具有空存儲類型的值被認為小于任何值（包括另外一個具有空存儲類型的值）。
b)一個整數(shù)值或實數(shù)值小于任何文本值和BLOB值。 當一個整數(shù)或實數(shù)和另一個整數(shù)或實數(shù)相比較的時候，則按照實際數(shù)值來比較。
c)一個文本值小于BLOB值。當兩個文本值相比較的時候，則用C語言類庫中的memcmp()函數(shù)來比較。然而，有時候也不是這樣的，比如在下面所描述的“用戶定義的整理順序”情況下。
d)當兩個BLOB文本被比較的時候，結果決定于memcmp()函數(shù)。
SQLite數(shù)據(jù)庫
SQLite是一款輕型的數(shù)據(jù)庫，是遵守ACID的關聯(lián)式數(shù)據(jù)庫管理系統(tǒng)，它的設計目標是嵌入式的，而且目前已經(jīng)在很多嵌入式產(chǎn)品中使用了它，它占用資源非常的低，在嵌入式設備中，可能只需要幾百K的內(nèi)存就夠了。它能夠支持Windows/Linux/Unix等等主流的操作系統(tǒng)，同時能夠跟很多程序語言相結合，比如Tcl、PHP、Java等，還有ODBC接口，同樣比起Mysql、PostgreSQL這兩款開源世界著名的數(shù)據(jù)庫管理系統(tǒng)來講，它的處理速度比他們都快。
【編輯推薦】
