經(jīng)查閱網(wǎng)上資料：?

一、關(guān)于數(shù)據(jù)庫簡介：?
SQLite??? 主頁：http://www.sqlite.org?
SQLite誕生于2000年5月，這幾年增長勢(shì)頭迅猛無比，目前版本是3.3.8。?

SQLite的特點(diǎn)如下：?

1、無需安裝配置，應(yīng)用程序只需攜帶一個(gè)動(dòng)態(tài)鏈接庫。?

2、非常小巧，For Windows 3.3.8版本的DLL文件才374KB。?

3、ACID事務(wù)支持，ACID即原子性、一致性、隔離性、和持久性（Atomic、Consistent、Isolated、和 Durable）。?

4、數(shù)據(jù)庫文件可以在不同字節(jié)順序的機(jī)器間自由的共享，比如可以直接從Windows移植到Linux或MAC。?

5、支持?jǐn)?shù)據(jù)庫大小至2TB。?

6、sqlite無疑是最小的一個(gè)，單文件程序，只有400k，而它生成的數(shù)據(jù)庫文件也是單文件。它支持大部份SQL92標(biāo)準(zhǔn)，不過遺憾的是不支持外鍵與存儲(chǔ)過程?

Firebird 嵌入服務(wù)器版（Embedded Server）?? 主頁：http://www.firebirdsql.org?
從Interbase開源衍生出的Firebird，充滿了勃勃生機(jī)。雖然它的體積比前輩Interbase縮小了幾十倍，但功能并無閹割。為了體現(xiàn)Firebird短小精悍的特色，開發(fā)小組在增加了超級(jí)服務(wù)器版本之后，又增加了嵌入版本，最新版本為2.0。?

Firebird的嵌入版有如下特色：?

1、數(shù)據(jù)庫文件與Firebird網(wǎng)絡(luò)版本完全兼容，差別僅在于連接方式不同，可以實(shí)現(xiàn)零成本遷移。?
2、數(shù)據(jù)庫文件僅受操作系統(tǒng)的限制，且支持將一個(gè)數(shù)據(jù)庫分割成不同文件，突破了操作系統(tǒng)最大文件的限制，提高了IO吞吐量。?
3、完全支持SQL92標(biāo)準(zhǔn)，支持大部分SQL-99標(biāo)準(zhǔn)功能。?
4、豐富的開發(fā)工具支持，絕大部分基于Interbase的組件，可以直接使用于Firebird。?
5、支持事務(wù)、存儲(chǔ)過程、觸發(fā)器等關(guān)系數(shù)據(jù)庫的所有特性。?
6、可自己編寫擴(kuò)展函數(shù)(UDF)。?
7、firebird其實(shí)并不是純粹的嵌入式數(shù)據(jù)庫，embed版只是其眾多版本中的一個(gè)。不過做的也很小，把幾個(gè)dll加起來才不到5M，但是它支持絕大部份SQL92與SQL99標(biāo)準(zhǔn)?

二、sqlite和FB比，關(guān)于損壞問題：?
1：突然停電或系統(tǒng)突然重啟動(dòng)導(dǎo)至數(shù)據(jù)損壞。sqlite對(duì)這方面很大程度上避免這個(gè)問題方面做得比較好。?
2：加密功能，不用擔(dān)心數(shù)據(jù)被別人復(fù)制到別的地方打開。而FB只要能復(fù)制到別的地方，隨便可以打開。?
3：頻煩的插入刪除，更新數(shù)據(jù)，不會(huì)導(dǎo)至數(shù)據(jù)數(shù)據(jù)庫很快增長。FB數(shù)據(jù)庫快速度增長是容易導(dǎo)至數(shù)據(jù)庫損壞的原因。?

這三個(gè)問題，是導(dǎo)至一個(gè)軟件是否長期使用時(shí)的可靠性問題。?
我使用了各種辦法想讓sqlite數(shù)據(jù)庫出現(xiàn)損壞（在操作數(shù)據(jù)庫時(shí)用突然斷電，強(qiáng)制殺死進(jìn)程，重新啟動(dòng)等等），都沒有辦到。而FB這樣折騰一會(huì)數(shù)據(jù)庫文件準(zhǔn)壞，且無法修復(fù)。?

三、sqlite和FB比，關(guān)于性能問題：?

http://www.jbxue.com/db/6334.html

SQLLite操作百萬級(jí)數(shù)據(jù)之優(yōu)化篇

描述:SQLite數(shù)據(jù)庫本質(zhì)上來講就是一個(gè)磁盤上的文件，所以一切的數(shù)據(jù)庫操作其實(shí)都會(huì)轉(zhuǎn)化為對(duì)文件的操作，而頻繁的文件操作將會(huì)是一個(gè)很耗時(shí)的過程，會(huì)極大地影響數(shù)據(jù)庫存取的速度。

描述:
SQLite數(shù)據(jù)庫本質(zhì)上來講就是一個(gè)磁盤上的文件，所以一切的數(shù)據(jù)庫操作其實(shí)都會(huì)轉(zhuǎn)化為對(duì)文件的操作，而頻繁的文件操作將會(huì)是一個(gè)很耗時(shí)的過程，會(huì)極大地影響數(shù)據(jù)庫存取的速度。例如：向數(shù)據(jù)庫中插入100萬條數(shù)據(jù)，在默認(rèn)的情況下執(zhí)行相應(yīng)的操作,就會(huì)打開和關(guān)閉文件100萬次，所以速度當(dāng)然會(huì)很慢。

分析:
在入庫和更新過程中按照數(shù)據(jù)庫事務(wù)的思想進(jìn)行設(shè)計(jì)：SQLite執(zhí)行入庫、更新操作的方式是，語句執(zhí)行對(duì)象句柄調(diào)用庫函數(shù)打開文件、調(diào)用函數(shù)執(zhí)行sql語句、關(guān)閉文件。這樣的執(zhí)行方式對(duì)于數(shù)量級(jí)別超大的文件的弊端就是每次執(zhí)行sql語句的時(shí)候都要打開文件（假設(shè)百萬級(jí)數(shù)量級(jí)的數(shù)據(jù)，就要打開和關(guān)閉文件百萬次），對(duì)于數(shù)據(jù)庫的入庫和更新操作時(shí)間主要都浪費(fèi)到了文件的打開和關(guān)閉操作上，所以這里增加事務(wù)以解決該問題.

解決:
SQLite數(shù)據(jù)庫是支持事務(wù)操作的，于是我們就可以通過事務(wù)來提高數(shù)據(jù)庫的讀寫速度。事務(wù)的基本原理是：數(shù)據(jù)庫管理系統(tǒng)首先會(huì)把要執(zhí)行的sql語句存儲(chǔ)到內(nèi)存當(dāng)中，只有當(dāng)commit()的時(shí)候才一次性全部執(zhí)行所有內(nèi)存中的數(shù)據(jù)庫。同時(shí),在.NET中對(duì)數(shù)據(jù)的操作還可以采用預(yù)編優(yōu)化的方式來提升性能,這種方式是采用IDbCommand的Prepare方法來進(jìn)行的。

示例:
以下引用網(wǎng)絡(luò)上的一個(gè)示例數(shù)據(jù)來說明一下效果
引用地址:http://www.cnblogs.com/Kevin-moon/archive/2008/12/01/1344658.html
A、系統(tǒng)環(huán)境
OS：Windows XP Professional Server Pack 3
CPU：AMD K8 3200+(2.2G)
RAM：3G
HD：Seagate 160G IDE 7200RPM

B、代碼環(huán)境
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)

下是測(cè)試數(shù)據(jù)，僅予參考
測(cè)3次平均，無測(cè)10W+，因Firebird出現(xiàn)OutMemoryException
無測(cè)修改操作，因無需求
依序 1、10、100、1000、10000 條數(shù)據(jù)，單位 ms

新增操作
1.無預(yù)編, 無事務(wù)
Access：41、54、195、1610、16187
Firebird：9、19、189、1929、22125
SQLite：3、27、867、5002、53603

2.事務(wù)控制
Access：39、50、162、1278、12366
Firebird：11、30、60、587、5904
SQLite：4、4、10、73、739

3.預(yù)編譯優(yōu)化
Access：43、50、128、908、9100
Firebird：2、13、128、1322、15954
SQLite：4、26、465、4626、54608

4.預(yù)編譯+事務(wù)控制
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性能不如預(yù)期、SQLite性能很好
Access事務(wù)支爰不強(qiáng)，但預(yù)編啟性能很好
SQLite缺省已預(yù)編，加上事務(wù)控制性能更好
Access查詢加排序，數(shù)據(jù)10W+時(shí)性能極差(I/O問題)
單測(cè)Firebird 10W+新增操作，性能極差(I/O問題)
10W+數(shù)據(jù)操作性能多卡在I/O，不過SQLite因規(guī)格單純，所以性能會(huì)較強(qiáng)

總結(jié):
1.通過事務(wù)一次提交多條SQL語句,以減少SQLLite數(shù)據(jù)的IO操作,可以有效提升大數(shù)據(jù)量操作的性能。
2.通過.NET中的預(yù)編譯優(yōu)化方式,即采用IDbCommand的Prepare方法來配合事務(wù)執(zhí)行大批量SQL操作,可以進(jìn)一步優(yōu)化其性能。

總結(jié)

以上是生活随笔為你收集整理的关于SQLite 与 FireBird 利弊分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。