sqlite應用情境

★如何權衡？
　　當你在權衡某個場合是否應該使用SQLite時，（在技術層面）至少要考慮如下幾點：
　　◇能否發揮SQLite的某些特長？
　　◇是否還有其它的替代方案？
　　◇是否有啥潛在的技術風險？
　　想清楚上述問題之後，再做出決策。

　　★SQLite的特點
　　關於SQLite的特長，在上次的文章中已經介紹過了。考慮到某些同學比較健忘，咱再回顧一下：
　　◇檔案型資料庫，且只有單一資料檔案
　　◇輕量級
　　◇綠色（不依賴其它軟體庫）
　　◇跨平台（包括引擎和資料檔案）
　　◇支援記憶體資料庫
　　◇支援較大的資料檔案（TB層級）

　　★可能的替代方案
　　剛才說了，權衡SQLite的使用需要考慮其它的替代方案，所以俺簡單介紹一下和SQLite用途相近的其它幾種技術手段。後面講應用情境的時候，會結合這幾個替代方案來作對比。

　　◇Access資料庫
　　Access資料庫也是檔案型的資料庫，支援的很多SQL特性都類似於SQLite。自從Windows 2000開始，Windows就內建了Access的資料庫引擎（Microsoft Jet Database Engine）。所以Access資料庫在上述系統中也是可以獨立啟動並執行（不依賴Office）。
　　Access資料庫最主要的缺點就是不能跨平台。另外還有幾個小缺點：檔案大小有限制（2GB）、不支援記憶體資料庫。

　　◇其它檔案型資料庫
　　其實，除了Access之外，還有另外一些檔案型資料庫。但是這些檔案型資料庫要麼名氣太小，要麼不支援多種程式設計語言（比如HSQLDB），要麼已經過時（比如FoxPro、Paradox）。所以後面分析應用情境的時候就不再提及這些玩意兒。

　　◇CSV檔案
　　CSV（Comma Separated Values，詳細解釋見“這裡”）是一種很簡單的純文字格式。它本身就是用來表示二維的資料資訊的。一個CSV檔案可以理解為資料庫的一張表。
　　CSV的缺點主要在於：不便於儲存非文本的資料資訊（比如BLOB類型的資訊）；如果需要同時儲存多張表的資訊，就需要對應有多個CSV檔案（檔案一多，就嫌麻煩）。

　　◇XML檔案
　　XML檔案想必大伙兒都知道，我就不多說了。XML格式主要缺點也有兩個：一個是由於XML本身是樹狀結構，有時候不便於表示二維資料表的資訊；另一個是資料量大（比如檔案超過10MB或者XML節點層次很深）的時候，解析XML的開銷蠻大的。

　　★作為資料庫的應用情境
　　前面說了一大通，現在開始切入正題，先說說SQLite作為一個輕型資料庫，方便幹哪些事兒？
　　在這類情境中，由於是把SQLite作為資料庫來使的，所以基本不用考慮CSV和XML這兩種替代方案。

　　◇需要資料庫的小型案頭軟體
　　如果你開發一個小型的案頭軟體並且需要用到資料庫功能（比如某個背單詞軟體），那SQLite是一個不錯的選擇。因為SQLite很綠色又很短小精悍。
　　不過，由於Windows在案頭系統的比重很大。對於那些不考慮跨平台的開發人員，SQLite相對於Access來說，沒有太大的優勢。

　　◇需要資料庫的手機軟體
　　眼下手機應用的發展很迅猛，相應的開發人員也多起來了。假如你就是一個手機應用程式的開發人員，並且你開發的應用需要有資料庫功能（比如某個字典工具），那SQLite簡直是不二之選。由於手機作業系統名目繁多，同時手機的記憶體偏小，這時候SQLite跨平台和輕量級的特長就充分發揮出來了。目前幾個知名的手機作業系統（比如Android、Windows Mobile、Symbin、Palm等），SQLite都支援得不錯。
　　在這種場合，Access基本沒戲。

　　★作為資料容器的應用情境
　　所謂資料容器，就是把SQLite作為裝資料的容器，充分發揮SQLite單一資料檔案的優點。另外，還可以避免自己定義一套資料檔案格式的麻煩。要知道，定義一個完善的資料檔案格式是難度極大滴（要考慮可擴充性、要考慮向下相容、假如跨CPU架構還要考慮位元組序、假如資料量大還要考慮效能、還要...）。

　　◇資料備份/恢複、資料匯入/匯出
　　某些軟體系統（尤其是些公司專屬應用程式系統）經常會碰到資料備份/恢複的功能需求。比如說，客戶會要求你把一些資料（往往是業務相關的）定期備份成一個獨立的資料檔案，然後儲存在別處。一旦軟體系統自身發生不測，再把備份的資料恢複回來。
　　另外，匯入/匯出功能也是經常碰到的。一般是某個軟體安裝在多個地方。然後需要把一些資料（往往是業務相關的）從A處匯出，然後在B處匯入。
　　針對上述這兩種需求：如果牽涉的資料比較大，就不宜使用XML或者Access；如果牽涉到跨平台，就無法使用Access；如果牽涉到多種資料，就不宜使用CSV（除非你能忍受多個CSV檔案並存）。有上述條件限制的地方，都很適合用SQLite。

　　◇線上升級
　　這年頭不連網的單機已經很少了，提供線上升級功能的軟體會多起來。一般的線上升級分為兩類：升級程式（比如Firefox自動升級新版本）和升級業務資料（比如殺毒軟體升級病毒庫）。這兩種類型都可以使用SQLite來完成。把需要要升級的內容放置到SQLite資料庫檔案中，將來升級時只需下載單一的升級檔案即可。
　　在這種情境，不太合適用CSV和XML。如果不考慮跨平台，倒也可以用Access來搞定。

　　★作為記憶體資料庫的應用情境
　　在這種類型的情境中，咱們要充分發揮SQLite記憶體資料庫的特長。由於SQLite的API設計比較合理，操作記憶體資料庫和操作檔案資料庫幾乎沒啥區別，所以從檔案型切換到記憶體型，代碼不用大改。另外，從3.6.11開始，SQLite增加了online backup介面，便於在記憶體資料庫和檔案資料庫之間進行資料的同步。

　　◇降低磁碟I/O開銷
　　比如開發了某個字典工具，詞庫儲存在SQLite資料庫檔案中。當詞庫越來越大的時候，你可能會發現，查詞的速度越來越慢。當然啦，速度慢未必是磁碟 I/O引起的。這時候你可以把程式略微修改一下（可能就10行左右的代碼），在初始化時把詞庫載入記憶體的SQLite資料庫中。然後再對比測試一下效能。如果發現效能有明顯提升，那你以後就可以一直用這種方式了。
　　使用這個招數，要小心記憶體資料庫對記憶體空間的佔用。比如對於普通的PC，佔用個幾兆、十幾兆還行，再大的話就不爽了。另外，對於手機作業系統，此招數效果不好（手機本身的記憶體就不是很大，而且儲存介質的速度已經蠻快了）。

　　◇作為暫存資料表
　　記憶體資料庫方式，還可以用來充當暫存資料表，存放一些臨時資料。當程式的進程退出時，記憶體資料庫就自然消失了，不會留下任何垃圾。
　　不過這種方式只適合於某個程式獨佔暫存資料表的情形。如果暫存資料表需要被多個進程共用，這招就不靈了。