1.0 內(nèi)容提要

    SQLite4 是一個放在庫中的緊湊的，自包含的，零維護的的ACID數(shù)據(jù)庫引擎, 像SQLite3一樣, 但具有改進的接口和文件格式.

    運行時環(huán)境封裝到了一個對象之中.

    使用了一個很不錯的鍵值對存儲引擎:

•         一個獨立的大型鍵空間 - 不是SQLite3中那種每個表單獨的鍵空間和索引.
•         按字典順序的鍵排序.
•         多個存儲引擎，可在運行時互換.
•         默認在磁盤上的存儲殷勤使用了一個日志結構的合并數(shù)據(jù)庫.

    表的PRIMARY KEY真正被用作存儲引擎的鍵.

    可以使用小數(shù)點運算.

    外鍵約束和遞歸觸發(fā)器默認是啟用的.

    覆蓋指數(shù)可以顯示聲明.

2.0 概述

SQLite4 對于SQLite3而言，是一個可選方案，而不是一個替代方案. SQLite3 還沒有過時. SQLite3 和 QLite4 將會并行受到支持. SQLite3 遺留的好處不會被拋棄.   SQLite3 還將會被持續(xù)的維護和改進. 但如果需要的話，新系統(tǒng)的設計者現(xiàn)在將可以選擇 SQLite4 而不是 SQLite3.

SQLite4 努力保持了SQLite3的最優(yōu)秀特性，同時在不破壞兼容性的前提下解決了SQLite3中無法修復的問題. SQLite3 和 SQLite4 中將會持續(xù)保持一樣的特性有:

•     SQLite4 是放在一個庫中并鏈接到一個大型應用程序的完整的，關系型，事務性的, ACID, SQL 數(shù)據(jù)庫引擎.  沒有服務器，I/O直接面向硬盤.
•     SQLite4 的源代碼任何人可以用于任何目的.  沒有版權、發(fā)布或者公開源代碼或者編譯二進制文件方面的的限制.  不用去擔心煩人的許可證.
•     使用了動態(tài)類型，而不是大多數(shù)其它的SQL數(shù)據(jù)庫引擎所使用的僵化的靜態(tài)類型.
•     (默認)在磁盤上的鏡像是一個單獨的使用良好且穩(wěn)定文件格式的磁盤文件, 使得SQLite4庫適合于作為一個應用程序的文件格式使用.
•     SQLite4 將會是快速且可靠的，無需管理員操心它就能運作的蠻好.
•     SQLite4 的實現(xiàn)只有最簡化的依賴，因而它可以很容易的集成到嵌入式系統(tǒng)或者其它非常規(guī)的運行時環(huán)境.

實現(xiàn)上仍然采用常用的匯編語言C。與SQLite3相比，SQLite4使用了更多C99特性，不過仍然可以使用常見的編譯器編譯。SQLite4使用了諸如size_t,int64_t,uint64_t以及其他標準數(shù)據(jù)類型。

SQLite4的編程接口與SQLite3的非常相似，只不過命名前綴都從sqlite3_更改為sqlite4_。SQLite3中舊的和作廢的接口已經(jīng)從SQLite4中剔除了。給一些函數(shù)增加了參數(shù)，有時對參數(shù)稍作修改或者對其參數(shù)順序進行重新排序。修改了某些接口名字，使其更加符合其功能。總體上來說，SQLite4的編程接口與SQLite3的非常相似，這樣移植一個SQLite3上的應用到SQLite4上只需花一個小時或者兩個小時完成搜索替代就可以了。

SQLite3和SQLite4沒有共用任何符號，因此把SQLite3和SQLite4同時嵌入到同一進程，同時使用它們都是可行的.

3.0 SQLite4的主要改變
3.1 運行時對象

SQLite4中一些接口的第一個參數(shù)接收一個（新加的）指向一個sqlite4_env對象的指針，它定義了運行時環(huán)境。需要接收sqlite4_env指針的示例程序包括：

•     sqlite4_open()
•     sqlite4_malloc(), sqlite4_realloc(), and     sqlite4_free()
•     sqlite4_mprintf()
•     sqlite4_random()
•     sqlite4_config()

一個sqlite4_env對象實例定義了SQLite4與其他系統(tǒng)交互是如何交互的。一個sqlite4_env對象包含的方法能夠：

•     分配，進入，離開和收回互斥體
•     分配，調(diào)整和釋放堆內(nèi)存，
•     訪問和控制底層鍵/值存儲引擎，
•     使用高質量隨機種子初始化內(nèi)建PRNG，
•     取得當前時間和日期與本地時區(qū),
•     記錄error日志消息.

標準平臺(windows和Unix)的SQLite4構建包含了一個全局sqlite4_env對象，通常這個對象適配于所在平臺。如果一個接口程序的參數(shù)中有一個指向sqlite4_env對象的指針，而且傳給這個參數(shù)的指針是空指針時，這個接口程序就會使用默認的全局sqlite4_env對象。另外，某些應用可能要求在相同的地址空間上運行兩個或者多個SQLite4實例，同時每個實例使用了各自不同的互斥原語，不同的內(nèi)存堆以及不同的時間日期函數(shù)等等。SQLite4通過對每個數(shù)據(jù)庫實例創(chuàng)建不同的sqlite4_env對象來滿足這種需求。sqlite4_env對象中還廢除了全局和靜態(tài)變量，這樣就可以非常容易地把SQLite4移植到哪些對靜態(tài)或者全局數(shù)據(jù)提供有限支持的嵌入式系統(tǒng)中。

3.2 簡化的鍵/值存儲引擎

相對于SQLite3，SQLite4使用的鍵/值存儲引擎擁有一個大大簡化了的接口。這個存儲引擎是可拔插的；通過對qlite4_env對象在打開新的數(shù)據(jù)庫連接前做適當?shù)母膭?，它可以在運行時被改變。

SQLite4 需要一個實現(xiàn)了有序鍵/值對的存儲引擎，它的鍵和值是任意長度的二進制數(shù)據(jù)。鍵必須惟一，且按字典排序。也就是說，鍵應該根據(jù)一個比較函數(shù)進行排序，例如：
 

給定一個探針鍵，SQLite4需要能夠找到它最近的鍵，然后以字典序升序或降序遍歷鍵。向一個已有的鍵插入數(shù)據(jù)時會覆蓋舊數(shù)據(jù)。事務，包括原子提交和回滾，由存儲引擎負責。

SQLite4經(jīng)由表和索引，將所有數(shù)據(jù)存儲到一個單獨的鍵空間， 與此相反，SQLite3中每個表和索引都需要一個單獨的鍵空間。SQLite4的存儲也與SQLite3不同，因為它需要存儲引擎以字典序對鍵進行排序， 而SQLite3使用了一個非常復雜的比較函數(shù)來決定記錄的存儲順序。

SQLite4與存儲引擎之間的通信是通過一個定義完善的并且簡單的接口進行的。新的存儲引擎可以在運行期間進行替換：只要在指定數(shù)據(jù)庫連接之前替換sqlite4_env對象里的某些函數(shù)指針就可以了。

如果替換的存儲引擎不支持回滾，那么這就意味著SQLite4無法運行ROLLBACK。如果替換的存儲引擎不支持事務嵌套，那么這就意味著SQLite4無法運行嵌套事務。因此，嵌入到SQLite4中的存儲引擎的功能越少，對應的整體的系統(tǒng)功能就會越差。

默認情況下內(nèi)置的存儲引擎是日志結構的合并式數(shù)據(jù)庫。它比LevelDB要快很多倍，支持嵌套式事務，它把整個內(nèi)容存儲在單一的磁盤文件里。SQLite4的未來版本還可能包含一個內(nèi)置的采用B樹結構的存儲引擎。

3.3 現(xiàn)在的PRIMARY KEY是真正的主鍵

Sqlite3允許聲明表中的任何單個或多列為主鍵。但在內(nèi)部，SQLite3只將PRIMARY KEY簡單地當做唯一約束來對待。實際中用于存儲使用的鍵是每一行的rowid。

Sqlite4則相反，它真實地使用聲明的表主鍵（更確切地說是PRIMARY KEY的編碼值）作為鍵而插入存儲引擎。SQLite4表通常沒有rowid（除非在表沒有PRIMARY KEY的情況下，這時需要一個rowid作為隱式主鍵。）這意味著內(nèi)容在磁盤中按主鍵的順序存儲。這也意味著可以通過對PRIMARY KEY的一次查詢即可定位記錄。在SQLite3中，主鍵上的一個搜索意味著在自動創(chuàng)建的索引中先找到rowid，然后依據(jù)該rowid對主表做一個二次搜索。

SQLite4 需要 PRIMARY KEY 的所有元素不能為空. 這是一條SQL標準.  由于早期版本的疏忽, SQLite3 沒有在PRIMARY KEY 列上強制加上這條NOT NULL約束，到該漏洞被發(fā)現(xiàn)的時候SQLite3已經(jīng)在被廣泛使用了, NOT NULL 約束的激活就可能會對太多的程序造成影響.
3.4 十進制數(shù)

SQLite4 使用十進制算數(shù)做所有的數(shù)字計算. SQLite4 從不使用C類型的double或者float(除了在double和內(nèi)部十進制表示之間轉換時使用語接口例程中).  相反，所有數(shù)字值在內(nèi)部表示方式為一個帶有3位數(shù)字的基于10的指數(shù)的18位十進制數(shù).  這一表示方式的特性有:

•     即使是在缺乏對于IEEE 754 binary64浮點數(shù)字支持的平臺上，其運作起來也是可靠和兼容的.
•     貨幣計算通?？梢跃_的進行，不需要四舍五入.
•     任何有符號和無符號的64位整數(shù)都能被精確的表示.
•     浮點數(shù)范圍和精確度超出了 IEEE 754 binary64 浮點數(shù).
•     正無窮和負無窮以及 NaN (Not-a-Number) 都有良好的表示方式.

SQLite4 使得整型和浮點型數(shù)字之間沒有了差別. 不過期卻有精確和近似數(shù)之間的分別. 在 C/C++ 中, 整形數(shù)是精確的而浮點數(shù)是近似的. 但SQLite4并不一定如此.  浮點數(shù)字在SQLite4可以是精確的.  可以用64位表示的整型數(shù)在SQLite4中總是精確的，而大型的整型數(shù)則可能是近似的.

SQLite4 數(shù)字格式是面向內(nèi)部使用的.  數(shù)字可以在整型和double型之間轉換，用于輸入和輸出.  磁盤上的存儲空間需要從1到12位的SQLite4數(shù)字值, 這取決于其大小和重要的位數(shù).

3.5 外鍵約束和遞歸觸發(fā)器是默認開啟的

外鍵約束在SQLite3的早期版本中是沒有的，并且他們默認關閉了向后兼容的能力。但是外鍵約束一直是有效的，并且在SQLite4中是默認打開的。所有的外鍵約束都是默認延遲的，盡管他們能夠被定義成立即創(chuàng)建。但是，沒有有效的機制去觸發(fā)外鍵約束，不管是延遲創(chuàng)建還是立即創(chuàng)建。

SQLite3提供了遞歸觸發(fā)器，但是這只是在一個運行時才有效的功能。在SQLite4中，所有的觸發(fā)器在所有的時間段里都是遞歸的。

3.6 明確的索引覆蓋

SQLite4 像 CREATE TABLE 語句中條件了一個可選的子句，該子句定義了在索引中重復的附加列信息. 這可以讓應用程序開發(fā)者在SQLite4中無需使用任何花招就可以明確地創(chuàng)建覆蓋索引.  例如:

CREATE INDEX cover1 ON table1(a,b) COVERING(c,d);

上面的 cover1 索引可以在存儲引擎中用一個單一的查找操作來進行形式如 "SELECT c,d FROM table1 WHERE a=?1 AND b=?2" 的查詢.  索引中如果沒有附加的 COVERING 子句, SQLite4 也許會在存儲引擎中做兩次操作; 一次操作基于a和b的值來找到主鍵，而第二次操作則基于主鍵來找到c和d的值. COVERING 子句使得c和d的值在索引中就可用，這意味著它們無需第二次查找就可以從索引中提取出來.

COVERING 語句上有一個變化:
 

CREATE INDEX cover2 ON table(x,y) COVERING ALL;

COVERING ALL 語句的意思是數(shù)據(jù)表的所有列都在索引中被重復一份，這就確保了原來的數(shù)據(jù)表永遠也不會被訪問到，以完成一個使用了這個索引的查詢.  這種方法的缺點，當然就是信息重復，而且因此讓數(shù)據(jù)庫文件更大.  但是通過在索引指標上明確指定COVERING關閉，SQLite4可以讓應用程序開發(fā)者權衡著從應用程序中騰出空間和時間來讓其更加適用.