大多數的數據庫引擎(到如今據咱們所知的除了sqlite的每一個sql數據庫引擎)都使用靜態的、剛性的類型,使用靜態類型,數據的類型就由它的容器決定,這個容器是這個指被存放的特定列。sql
Sqlite使用一個更通常的動態類型系統,sqlite中,值的數據類型跟值自己相關,而不是與它的容器相關。Sqlite的動態類型系統和其餘數據庫的更爲通常的靜態類型系統相兼容,但同時,sqlite中的動態類型容許它能作到一些傳統剛性類型數據庫所不可能作到的事。數據庫
1. 存儲類和數據類型app
每一個存放在sqlite數據庫中(或者由這個數據庫引擎操做)的值都有下面中的一個存儲類:less
l NULL,值是NULLide
l INTEGER,值是有符號整形,根據值的大小以1,2,3,4,6或8字節存放函數
l REAL,值是浮點型值,以8字節IEEE浮點數存放this
l TEXT,值是文本字符串,使用數據庫編碼(UTF-8,UTF-16BE或者UTF-16LE)存放編碼
l BLOB,只是一個數據塊,徹底按照輸入存放(即沒有準換)spa
從上能夠看出存儲類比數據類型更通常化。好比INTEGER存儲類,包括6中不一樣長度的不一樣整形數據類型,這在磁盤上形成了差別。可是隻要INTEGER值被從磁盤讀出進入到內存進行處理,它們被轉換成最通常的數據類型(8-字節有符號整形)。sqlite
Sqlite v3數據庫中的任何列,除了整形主鍵列,能夠用於存儲任何一個存儲列的值。sql語句中的中全部值,無論它們是嵌入在sql文本中或者是做爲參數綁定到一個預編譯的sql語句,它們的存儲類型都是未定的。在下面描述的狀況中,數據庫引擎會在查詢執行過程當中在數值(numeric)存儲類型(INTEGER和REAL)和TEXT之間轉換值。
1.1布爾類型
Sqlite沒有單獨的布爾存儲類型,它使用INTEGER做爲存儲類型,0爲false,1爲true
1.2 Date和Time Datatype
Sqlite沒有另外爲存儲日期和時間設定一個存儲類集,內置的sqlite日期和時間函數可以將日期和時間以TEXT,REAL或INTEGER形式存放
l TEXT 做爲IS08601字符串("YYYY-MM-DD HH:MM:SS.SSS")
l REAL 從格林威治時間11月24日,4174 B.C中午以來的天數
l INTEGER 從 1970-01-01 00:00:00 UTC以來的秒數
程序能夠任意選擇這幾個存儲類型去存儲日期和時間,而且可以使用內置的日期和時間函數在這些格式間自由轉換
2.0 類型近似
爲了使sqlite和其餘數據庫間的兼容性最大化,sqlite支持列上「類型近似」的觀點,列的類型近似指的是存儲在列上數據的推薦類型。這裏必須記住一點,這個類型是被推薦,而不是必須的。任何列仍然能存儲任意類型的數據。只是一些列,給予選擇的話,將會相比於其餘的一些類型優選選擇一些存儲類型,這個列優先選擇的存儲類型被稱爲它的「近似」。
每一個sqlite3數據庫中的列都被賦予下面類型近似中的一種:
l TEXT
l NUMERIC
l INTEGER
l REAL
l NONE
具備TEXT近似的列能夠用NULL,TEXT或者BLOB類型存儲數據。若是數值數據被插入到具備TEXT近似的列,在被存儲前被轉換爲文本形式
一個有NUMERIC近似的列可使用1中的全部5中存儲類來存儲數據。當文本數據被存放到NUMERIC近似的列中,這個文本的存儲類被轉換到INTEGER或REAL(根據優先級順序),若是這個轉換是無損的話。對於TEXT和REAL存儲類間的轉換,若是數據的前15位的被保留的話sqlite就認爲這個轉換是無損的、可反轉的。若是TEXT到INTEGER或REAL的轉換不可避免的會形成損失,那麼數據將使用TEXT存儲類存儲。不會企圖去轉換NULL或BLOB值。
一個字符串可能看起來像浮點數據,有小數點或指數符號,可是隻要這個數據可使用整形存放,NUMERIC近似就會將它轉換到整形。好比,字符串 '3.0e+5'存放到一個具備NUMERIC近似的列中,被存爲300000,而不是浮點型值300000.0。
具備INTEGER近似的列和具備NUMERIC近似的列表現相同。它們之間的差異僅處於轉換描述上。
具備REAL近似的列和具備NUMERIC近似的列同樣,除了它將整形數據轉換成浮點型形式。
具備NONE近似的列不會優先選擇一個存儲列,也不會強制將數據從一個存儲類轉換到另一個類。
2.1 列近似的決定因素
列的近似由這個列的聲明類型所決定,根據下面的順序的規則:
<1> 若是聲明類型包含」INT」字符串,那麼這個列被賦予INTEGER近似
<2> 若是這個列的聲明類型包含」CHAR」,」CLOB」,或者」TEXT」中的任意一個,那麼這個列就有了TEXT近似。注意類型VARCHAR包含了」CHAR」字符串,那麼也就被賦予了TEXT近似
<3> 若是列的聲明類型中包含了字符串」BLOB」或者沒有爲其聲明類型,這個列被賦予NONE近似
<4> 其餘的狀況,列被賦予NUMERIC近似
上面規則額順序對於決定列的近似很重要。一個列的聲明類型爲」CHARINT」的話同時會匹配規則<1>和<2>,可是第一個規則佔有優先級因此這個列的近似將是INTEGER。
2.2 近似名稱例子
下面這個表顯示了多少來自更傳統的SQL操做的普通數據類型名稱,使用上一節中的5個規則,被轉換到近似類型。這個表只顯示了sqlite可以接受的數據類名稱的一個子集。注意到跟隨類型名的圓括號內的數值參數(如:」VARCHAR(255)」)被sqlite忽略—sqlite不在字符串、BLOBS或者數值的長度上強加任何長度限制(除了一個全局的SQLITE_MAX_LENGTH限制)。
來自create table語句或者強轉語句的範例類型名 |
產生的近似 |
用於決定近似的規則 |
INT |
INTEGER |
1 |
CHARACTER(20) |
TEXT |
2 |
BLOB |
NONE |
3 |
REAL |
REAL |
4 |
NUMERIC |
NUMERIC |
5 |
注意到聲明類型爲」FLOATING POINT」將被賦予INTEGER近似,而不是REAL近似,由於在」POINT」中的」INT」。聲明類型爲」STRING」的將被賦予NUMERIC,而不是TEXT(由於上述表中定義的類型中不存在STRING這一類型,它被歸於到規則<4>中,屬於其餘狀況)。
(從上面能夠看出,sqlite3只是從聲明類型字符串中去查找它知道的聲明類型,好比」XINT」將被賦予INTEGER近似由於這個字符串裏面有」INT」,因此這裏並不須要一個單獨的正確的聲明類型,而是隻要聲明類型字符串裏面包含了sqlite所知道的聲明類型便可)
2.3 列近似操做例子
CREATE TABLE t1(
t TEXT, -- text affinity by rule 2
nu NUMERIC, -- numeric affinity by rule 5
i INTEGER, -- integer affinity by rule 1
r REAL, -- real affinity by rule 4
no BLOB -- no affinity by rule 3
); //這裏根據聲明類型肯定了列的類型近似
INSERT INTO t1 VALUES('500.0', '500.0', '500.0', '500.0', '500.0');
SELECT typeof(t), typeof(nu), typeof(i), typeof(r), typeof(no) FROM t1;
//結果:text|integer|integer|real|text
DELETE FROM t1;
INSERT INTO t1 VALUES(500.0, 500.0, 500.0, 500.0, 500.0);
SELECT typeof(t), typeof(nu), typeof(i), typeof(r), typeof(no) FROM t1;
//結果:text|integer|integer|real|real
DELETE FROM t1;
INSERT INTO t1 VALUES(500, 500, 500, 500, 500);
SELECT typeof(t), typeof(nu), typeof(i), typeof(r), typeof(no) FROM t1;
//結果:text|integer|integer|real|integer
(這裏的第四個值,對應的列是REAL近似的,傳輸的值整形的,可是根據REAL近似的規則它會將它轉換爲real型數據)
// 數據塊(BLOB)不論是什麼列近似都一直存爲BLOB類型
DELETE FROM t1;
INSERT INTO t1 VALUES(x'0500', x'0500', x'0500', x'0500', x'0500');
SELECT typeof(t), typeof(nu), typeof(i), typeof(r), typeof(no) FROM t1;
//結果:blob|blob|blob|blob|blob
// NULLs也不受列近似影響
DELETE FROM t1;
INSERT INTO t1 VALUES(NULL,NULL,NULL,NULL,NULL);
SELECT typeof(t), typeof(nu), typeof(i), typeof(r), typeof(no) FROM t1;
//結果:null|null|null|null|null
3.0 比較表達式
Sqlite v3有一系列有用的比較操做符,包括 "=", "==", "<", "<=", ">", ">=", "!=", "<>", "IN", "NOT IN", "BETWEEN", "IS", 和 "IS NOT"
3.1 排序
比較操做的結果基於操做數的存儲類型,根據下面的規則:
l 存儲類型爲NULL的值被認爲小於其餘任何的值(包括另外一個存儲類型爲NULL的值)
l 一個INTEGER或REAL值小於任何TEXT或BLOB值。當一個INTEGER或REAL值與另一個INTEGER或REAL值比較的話,就執行數值比較
l TEXT值小於BLOB值。當兩個TEXT值比較的時候,就根據序列的比較來決定結果
l 當兩個BLOB值比較的時候,使用memcmp來決定結果
3.2 比較操做數的近似(Affinity)
Sqlite可能在執行一個比較以前會在INTEGER,REAL或TEXT之間轉換比較值。是否在比較操做以前發生轉換基於操做數的近似(類型)。操做數近似(類型)由下面的規則決定:
l 對一個列的簡單引用的表達式與這個列有相同的affinity,注意若是X和Y.Z是列名,那麼+X和+Y.Z均被認爲是用於決定affinity的表達式
l 一個」CAST(expr as type)」形式的表達式與用聲明類型爲」type」的列有相同的affinity
l 其餘的狀況,一個表達式爲NONE affinity
3.3 在比較前的類型轉換
只有在轉換是無損、可逆轉的時候「應用近似」才意味着將操做數轉換到一個特定的存儲類。近似在比較以前被應用到比較的操做數,遵循下面的規則(根據前後順序):
l 若是一個操做數有INTEGER,REAL或NUMERIC近似,另外一個操做數有TEXT或NONE近似,那麼NUMERIC近似被應用到另外一個操做數
l 若是一個操做數有TEXT近似,另外一個有NONE近似,那麼TEXT近似被應用到另外一個操做數
l 其餘的狀況,不該用近似,兩個操做數按原本的樣子比較
表達式"a BETWEEN b AND c"表示兩個單獨的二值比較」 a >= b AND a <= c」,即便在兩個比較中不一樣的近似被應用到’a’。
3.4 比較舉例
CREATE TABLE t1(
a TEXT, -- text affinity
b NUMERIC, -- numeric affinity
c BLOB, -- no affinity
d -- no affinity
);
INSERT INTO t1 VALUES('500', '500', '500', 500);
SELECT typeof(a), typeof(b), typeof(c), typeof(d) FROM t1;
text|integer|text|integer
-- Because column "a" has text affinity, numeric values on the
-- right-hand +side of the comparisons are converted to text before
-- the comparison occurs.
SELECT a < 40, a < 60, a < 600 FROM t1;
0|1|1
-- Text affinity is applied to the right-hand operands but since
-- they are already TEXT this is a no-op; no conversions occur.
SELECT a < '40', a < '60', a < '600' FROM t1;
0|1|1
-- Column "b" has numeric affinity and so numeric affinity is applied
-- to the operands on the right. Since the operands are already numeric,
-- the application of affinity is a no-op; no conversions occur. All
-- values are compared numerically.
SELECT b < 40, b < 60, b < 600 FROM t1;
0|0|1
-- Numeric affinity is applied to operands on the right, converting them
-- from text to integers. Then a numeric comparison occurs.
SELECT b < '40', b < '60', b < '600' FROM t1;
0|0|1
-- No affinity conversions occur. Right-hand side values all have
-- storage class INTEGER which are always less than the TEXT values
-- on the left.
SELECT c < 40, c < 60, c < 600 FROM t1;
0|0|0
-- No affinity conversions occur. Values are compared as TEXT.
SELECT c < '40', c < '60', c < '600' FROM t1;
0|1|1
-- No affinity conversions occur. Right-hand side values all have
-- storage class INTEGER which compare numerically with the INTEGER
-- values on the left.
SELECT d < 40, d < 60, d < 600 FROM t1;
0|0|1
-- No affinity conversions occur. INTEGER values on the left are
-- always less than TEXT values on the right.
SELECT d < '40', d < '60', d < '600' FROM t1;
1|1|1
從這裏能夠看出,假如可使用3.1中的規則進行比較的話,就不須要進行類型轉換,不然的話就要進行類型轉換
4.0 操做符
全部的數學操做符(+, -, *, /, %, <<, >>, &, |),在被執行前,都會將兩個操做數都轉換爲數值存儲類型(INTEGER和REAL)。即便這個轉換是有損和不可逆的,轉換仍然會執行。一個數學操做符上的NULL操做數將產生NULL結果。一個數學操做符上的操做數,若是以任何方式看都不像數字,而且又不爲空的話,將被轉換爲0或0.0。