SQLite 適用場景

SQLite最佳試用場合

• 網站

  做爲數據庫引擎SQLite適用於中小規模流量的網站(也就是說, 99.9%的網站). SQLite能夠處理多少網站流量在於網站的數據庫有多大的壓力. 一般來講, 若是一個網站的點擊率少於100000次/天的話, SQLite是能夠正常運行的. 100000次/天是一個保守的估計, 不是一個準確的上限. 事實證實, 即便是10倍的上述流量的狀況下SQLite依然能夠正常運行.

• 嵌入式設備和應用軟件

  由於SQLite數據庫幾乎不須要管理, 所以對於那些無人值守運行或無人工技術支持的設備或服務, SQLite是一個很好的選擇. SQLite能很好的適用於手機, PDA, 機頂盒, 以及其餘儀器. 做爲一個嵌入式數據庫它也可以很好的應用於客戶端程序.

• 應用程序文件格式

  SQLite做爲桌面應用程序的本地磁盤文件格式取得了巨大成功.例如金融分析工具、CAD 包、檔案管理程序等等. 通常的數據庫打開操做須要調用sqlite3_open()函數，而且標記一個顯式本地事務的起始點（BEGIN TRANSACTION）來保證以獨佔的方式獲得文件的內容. 文件保存將執行一個提交（COMMIT）同時標記另外一個顯式本地事務起始點. 這種事務處理的做用就是保證對於應用程序數據文件的更新是原子的、持久的、獨立的和一致的.

  數據庫裏能夠加入一些臨時的觸發器,用來把全部的改變記錄在一張臨時的取消/重作日誌表中. 當用戶按下取消/重作按鈕的時候這些改變將能夠被回滾. 應用這項技術實現一個無限級的取消/重作功能只須要編寫不多的代碼.

• 替代某些特別的文件格式

  許多程序使用fopen(), fread(), 或 fwrite()函數建立和管理一些自定義的文件用來保存數據. 使用SQLite替代這些自定義的文件格式將是一種很好的選擇.

• 內部的或臨時的數據庫

  對於那些有大量的數據須要用不一樣的方式篩選分類的程序, 相對於編寫一樣功能的代碼, 若是你把數據讀入一個內存中的SQLite數據庫, 而後使用鏈接查詢和ORDER BY子句按必定的順序和排列提取須要的數據, 一般會更簡單和快速. 按照上述的方法使用內嵌的SQLite數據庫將會使程序更富有靈活性, 由於添加新的列或索引不用重寫任何查詢語句.

• 命令行數據集分析工具

  有經驗的SQL用戶可使用SQLite命令行程序去分析各類混雜的數據集. 原是數據能夠從CSV（逗號分隔值文件）文件中導入, 而後被切分產生無數的綜合數據報告. 可能得用法包括網站日誌分析, 運動統計分析, 編輯規劃標準, 分析試驗結果.

  固然你也能夠用企業級的客戶端/服務器數據庫來作一樣的事情. 在這種狀況下使用SQLite的好處是: SQLite的部署更爲簡單而且結果數據庫是一個單獨的文件, 你能夠把它存儲在軟盤或者優盤或者直接經過email發給同事.

• 在Demo或測試版的時候做爲企業級數據庫的替代品

  若是你正在編寫一個使用企業級數據庫引擎的客戶端程序, 使用一個容許你鏈接不一樣SQL數據庫引擎的通用型數據庫後臺將是頗有意義的. 其更大的意義在於將SQLite數據庫引擎靜態的鏈接到客戶端程序當中，從而內嵌SQLite做爲混合的數據庫支持. 這樣客戶端程序就可使用SQLite數據庫文件作獨立的測試或者驗證.

• 數據庫教學

  由於SQLite的安裝和使用很是的簡單(安裝過程幾乎忽略不計, 只須要拷貝SQLite源代碼或sqlite.exe可執行文件到目標主機, 而後直接運行就能夠) 因此它很是適合用來說解SQL語句. 同窗們能夠很是簡單的建立他們喜歡的數據庫, 而後經過電子郵件發給老師批註或打分. 對於那些感興趣怎樣實現一個關係型數據庫管理系統（RDBMS）的高層次的學生, 按照模塊化設計且擁有很好的註釋和文檔的SQLite源代碼, 將爲他們打下良好的基礎. 這並非說SQLite就是如何實現其餘數據庫引擎的精確模型, 可是很適合學生們瞭解SQLite是如何快速工做的, 從而掌握其餘數據庫系統的設計實現原則.

• 試驗SQL語言的擴展

  SQLite簡單且模塊化的設計使得它能夠成爲一個用來測試數據庫語言特性或新想法的優秀的原型平臺.

不適用場景

• 客戶端/服務器程序

   

  若是你有許多的客戶端程序要經過網絡訪問一個共享的數據庫, 你應當考慮用一個客戶端/服務器數據庫來替代SQLite. SQLite能夠經過網絡文件系統工做, 可是由於和大多數網絡文件系統都存在延時, 所以執行效率不會很高. 此外大多數網絡文件系統在實現文件邏輯鎖的方面都存在着bug(包括Unix 和windows). 若是文件鎖沒有正常的工做, 就可能出如今同一時間兩個或更多的客戶端程序更改同一個數據庫的同一部分, 從而致使數據庫出錯. 由於這些問題是文件系統執行的時候本質上存在的bug, 所以SQLite沒有辦法避免它們.

  好的經驗告訴咱們, 應該避免在許多計算機須要經過一個網絡文件系統同時訪問同一個數據庫的狀況下使用SQLite.

• 高流量網站

  SQLite一般狀況下用做一個網站的後臺數據庫能夠很好的工做. 可是若是你的網站的訪問量大到你開始考慮採起分佈式的數據庫部署, 那麼你應當堅決果斷的考慮用一個企業級的客戶端/服務器數據庫來替代SQLite.

• 超大的數據集

  當你在SQLite中開始一個事務處理的時候(事務處理會在任何寫操做發生以前產生, 而不是必需要顯示的調用BEGIN...COMMIT), 數據庫引擎將不得不分配一小塊髒頁(文件緩衝頁面)來幫助它本身管理回滾操做. 每1MB的數據庫文件SQLite須要256字節. 對於小型的數據庫這些空間不算什麼, 可是當數據庫增加到數十億字節的時候, 緩衝頁面的尺寸就會至關的大了. 若是你須要存儲或修改幾十GB的數據, 你應該考慮用其餘的數據庫引擎.

• 高併發訪問

  SQLite對於整個數據庫文件進行讀取/寫入鎖定. 這意味着若是任何進程讀取了數據庫中的某一部分, 其餘全部進程都不能再對該數據庫的任何部分進行寫入操做. 一樣的, 若是任何一個進程在對數據庫進行寫入操做, 其餘全部進程都不能再讀取該數據庫的任何部分. 對於大多數狀況這不算是什麼問題. 在這些狀況下每一個程序使用數據庫的時間都很短暫, 而且不會獨佔, 這樣鎖定至多會存在十幾毫秒. 可是若是有些程序須要高併發, 那麼這些程序就須要尋找其餘的解決方案了.