SQLite的侷限性

sql-92特性方面

正如前面提到的，sqlite不支援sql-92的在很多企業資料庫系統中可用的一些特性。

如：外來鍵約束（可解析的，但非強制）

很多alter table特性

一些trigger相關的特性

right和full outer join

更新乙個view

grant和revoke

你可以在sqlite的主頁上獲取最新資訊。

低併發操作

sqlite只支援平面事務；它沒有巢狀和營救點能力。巢狀意味著在乙個事務中可以有子事務的能力。營救點允許乙個事務返回到前面已經到達的狀態。它沒有能力確保高層次事務的併發。它允許在單個的資料庫檔案上多個併發的讀事務，但是只能有乙個排他的寫事務。這個侷限性意味著如果有事務在讀資料庫檔案的一部分，所有其他的事務將被禁止寫該檔案的任何一部分。類似的，如果有事務在寫資料庫檔案的一部分，所有其他事務將被禁止讀或者寫該檔案的任何一部分。

應用限制

因為它事務處理的有限併發，sqlite只擅長處理小型的事務。在很多情況下，這不是問題。每個應用迅速的完成它的資料庫工作然後繼續前進，因此沒有乙個事務會持有資料庫超過多少毫秒。但是在一些應用中，特別是寫入密集的，要求更多的併發的事務處理（表或者行級別的而不是資料庫級別的）那麼你將要為該應用使用其他不同的dbms。sqlite並不打算成為乙個企業dbms。他最適合於實現，維護和管理的簡單性比商業資料庫的無盡複雜特性更為重要的情況。

nfs問題

sqlite使用本地檔案鎖原語來控制事務處理的併發性。如果資料庫檔案駐留在網路分割槽上，可能會導致檔案鎖不能工作。很多的nfs實現被認為在它們的檔案鎖中是有bug的（在unix和windows上）。如果檔案鎖不能像預計的一樣工作，那麼就可能會有兩個或兩個以上的應用程式在同時修改相同資料庫的同一部分，導致了資料庫的毀壞。因為這個問題的出現是因為位於下層的檔案系統的實現的bug，所以sqlite沒有辦法阻止它的發生

另一原因是大多數網路檔案系統的連線延時，效果不是很好。在這種環境下，在資料庫檔案必須要跨網路訪問的情況下，實現了客戶端-伺服器的模型的dbms會比sqlite更有效。

資料庫規模

因為它的開發人員的開發設計選擇，sqlite可能不是乙個做非常大型的資料庫好選擇。在理論上,乙個資料庫檔案檔案可以有2tb（241）。日誌子系統的記憶體開銷和資料庫大小是成比例的。對每個寫事務，無論事務實際是寫是讀那個頁，sqlite為每個資料庫頁維護乙個記憶體內資訊位。預設的頁大小是1024位元組。即使如此，對乙個有超過幾百萬頁的資料庫，記憶體開銷可能成為乙個嚴重的瓶頸。

物件的數目和型別

乙個表或者索引被限制為最多有264 – 1個項。當然，你不可能有這麼多的條目，因為資料庫的241位元組大小限制。在sqlite的當前的實現中，乙個單獨的條目能夠持有230位元組的資料。（下層的檔案格式支援行大小相當於262位元組的資料。）在開啟乙個資料庫檔案時，sqlite會閱讀並且預處理來自主目錄表的所有條目並且建立很多記憶體目錄物件。所以，為了最好的效能，最好控制表，索引，檢視和觸發器的數目。同樣雖然沒有限制表中列的數目，超過幾百列還是似乎太過的。只有表開始的31列是候選為必然被優化的。你能夠在乙個索引中盡可能加入列，但是有超過30列的索引將不會被用來優化。

宿主變數引用

在一些嵌入dbms中，sql語句能夠直接引用宿主變數（即來自應用程式空間的那些值）。在sqlite中這是不行的。作為替代sqlite允許使用sqlite3_bind_* api函式來對輸入引數而不是輸出值繫結對sql語句宿主變數。這種策略通常比直接的訪問策略更好，因為後者需要特殊的預處理來將sql語句轉化為特殊的api呼叫。

儲存過程

很多dbms有被稱為儲存過程的能力來建立和儲存。儲存過程是形成邏輯作業單元和執行特殊任務的一組sql語句。sql查詢過程能夠使用這些過程。sqlite沒有這個能力。

文章出處：http://www.diybl.com/course/7_databases/sql/sqlserver/200838/103309.html

SQLite的侷限性

SQLite的侷限性

時代侷限性

AutoPtr 的侷限性

SQLite的侷限性

SQLite的侷限性

時代侷限性

AutoPtr 的侷限性

相關推薦