經查閱網上資料：
一、關於資料庫簡介：
sqlite 主頁：
sqlite誕生於2023年5月，這幾年增長勢頭迅猛無比，目前版本是3.3.8。
sqlite的特點如下：
1、無需安裝配置，應用程式只需攜帶乙個動態鏈結庫。
2、非常小巧，for windows 3.3.8版本的dll檔案才374kb。
3、acid事務支援，acid即原子性、一致性、隔離性、和永續性（atomic、consistent、isolated、和 durable）。
4、資料庫檔案可以在不同位元組順序的機器間自由的共享，比如可以直接從windows移植到linux或mac。
5、支援資料庫大小至2tb。
6、sqlite無疑是最小的乙個，單檔案程式，只有400k，而它生成的資料庫檔案也是單檔案。它支援大部份sql92標準，不過遺憾的是不支援外來鍵與儲存過程
firebird 嵌入伺服器版（embedded server） 主頁：
從interbase開源衍生出的firebird，充滿了勃勃生機。雖然它的體積比前輩interbase縮小了幾十倍，但功能並無閹割。為了體現firebird短小精悍的特色，開發小組在增加了超級伺服器版本之後，又增加了嵌入版本，最新版本為2.0。
firebird的嵌入版有如下特色：
1、資料庫檔案與firebird網路版本完全相容，差別僅在於連線方式不同，可以實現零成本遷移。
2、資料庫檔案僅受作業系統的限制，且支援將乙個資料庫分割成不同檔案，突破了作業系統最大檔案的限制，提高了io吞吐量。
3、完全支援sql92標準，支援大部分sql-99標準功能。
4、豐富的開發工具支援，絕大部分基於interbase的元件，可以直接使用於firebird。
5、支援事務、儲存過程、觸發器等關聯式資料庫的所有特性。
6、可自己編寫擴充套件函式(udf)。
7、firebird其實並不是純粹的嵌入式資料庫，embed版只是其眾多版本中的乙個。不過做的也很小，把幾個dll加起來才不到5m，但是它支援絕大部份sql92與sql99標準
二、sqlite和fb比，關於損壞問題：
1：突然停電或系統突然重啟動導至資料損壞。sqlite對這方面很大程度上避免這個問題方面做得比較好。
2：加密功能，不用擔心資料被別人複製到別的地方開啟。而fb只要能複製到別的地方，隨便可以開啟。
3：頻煩的插入刪除，更新資料，不會導至資料資料庫很快增長。fb資料庫快速度增長是容易導至資料庫損壞的原因。
這三個問題，是導至乙個軟體是否長期使用時的可靠性問題。
我使用了各種辦法想讓sqlite資料庫出現損壞（在運算元據庫時用突然斷電，強制殺死程序，重新啟動等等），都沒有辦到。而fb這樣折騰一會資料庫檔案準壞，且無法修復。
三、sqlite和fb比，關於效能問題：
描述:sqlite資料庫本質上來講就是乙個磁碟上的檔案，所以一切的資料庫操作其實都會轉化為對檔案的操作，而頻繁的檔案操作將會是乙個很耗時的過程，會極大地影響資料庫訪問的速度。
描述:sqlite資料庫本質上來講就是乙個磁碟上的檔案，所以一切的資料庫操作其實都會轉化為對檔案的操作，而頻繁的檔案操作將會是乙個很耗時的過程，會極大地影響資料庫訪問的速度。例如：向資料庫中插入100萬條資料，在預設的情況下執行相應的操作,就會開啟和關閉檔案100萬次，所以速度當然會很慢。
分析:在入庫和更新過程中按照資料庫事務的思想進行設計：sqlite執行入庫、更新操作的方式是，語句執行物件控制代碼呼叫庫函式開啟檔案、呼叫函式執行sql語句、關閉檔案。這樣的執行方式對於數量級別超大的檔案的弊端就是每次執行sql語句的時候都要開啟檔案（假設百萬級數量級的資料，就要開啟和關閉檔案百萬次），對於資料庫的入庫和更新操作時間主要都浪費到了檔案的開啟和關閉操作上，所以這裡增加事務以解決該問題.
解決:sqlite資料庫是支援事務操作的，於是我們就可以通過事務來提高資料庫的讀寫速度。事務的基本原理是：資料庫管理系統首先會把要執行的sql語句儲存到記憶體當中，只有當commit()的時候才一次性全部執行所有記憶體中的資料庫。同時,在.net中對資料的操作還可以採用預編優化的方式來提公升效能,這種方式是採用idbcommand的prepare方法來進行的。
b、**環境
net2.0、access2003、firebird 2.1.1.17910、sqlite 3.6.3
firebird data provider(firebirdsql.data.firebirdclient.dll, 2.1.0.0)
sqlite data provider(system.data.sqlite, 1.0.60.0)
下是測試資料，僅予參考
測3次平均，無測10w+，因firebird出現outmemoryexception
無測修改操作，因無需求
依序 1、10、100、1000、10000 條資料，單位 ms
新增操作
1.無預編, 無事務
access：41、54、195、1610、16187
firebird：9、19、189、1929、22125
sqlite：3、27、867、5002、53603
2.事務控制
access：39、50、162、1278、12366
firebird：11、30、60、587、5904
sqlite：4、4、10、73、739
3.預編譯優化
access：43、50、128、908、9100
firebird：2、13、128、1322、15954
sqlite：4、26、465、4626、54608
4.預編譯+事務控制
access：42、46、102、676、6355
firebird：3、4、22、211、2087
sqlite：3、4、8、41、378
查詢比較
access：39、42、40、51、181
firebird：2、3、15、131、1294
sqlite：1、1、3、16、165
討論：firebird效能不如預期、sqlite效能很好
access事務支爰不強，但預編啟效能很好
sqlite預設已預編，加上事務控制效能更好
access查詢加排序，資料10w+時效能極差(i/o問題)
單測firebird 10w+新增操作，效能極差(i/o問題)
10w+資料操作效能多卡在i/o，不過sqlite因規格單純，所以效能會較強
總結:1.通過事務一次提交多條sql語句,以減少sqllite資料的io操作,可以有效提公升大資料量操作的效能。
2.通過.net中的預編譯優化方式,即採用idbcommand的prepare方法來配合事務執行大批量sql操作,可以進一步優化其效能。
關於sqlite 加密
在移動裝置上，不管是ios還是android大家都喜歡使用sqlite，它體積小功能卻不錯，滿足大家的需求。但是使用過大家都清楚免費版sqlite資料是明文的，如果存放的是使用者敏感資訊，只要取出應用中的資料庫，神馬使用者名稱，密碼都一目了然。那麼你還敢使用手機登入什麼網銀神馬的麼？使用免費版本的沒...
關於sqlite多執行緒
1 如果是sqlite open fullmutex，也就是序列化方式，則對於連線時互斥的，只有乙個連線關閉，另外乙個連線才能讀寫 2 如果是sqlite open nomutex，則是多執行緒模式，對於寫是互斥的，但是如果乙個連線持續寫，另外乙個連線是無法寫入的，只能是錯誤或者超時返回。不過乙個連...
Android 關於SQLite事務
應用程式初始化有可能需要批量的向 sqlite 中插入大量資料，單獨的使用 迴圈插入的 方法會導致應用響應緩慢,因為 sqlite 插入資料的時候預設一條語句就是乙個事務，有多少條資料就有多少次磁碟操作。我的應用初始 5000 條記錄也就是要 5000 次讀寫磁碟操作。那我們就可以新增事務處理，把 ...