关于SQLite 与 FireBird 利弊分析
一、关于数据库简介：
SQLite 主页：http://www.sqlite.org
SQLite诞生于2000年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） 主页：http://www.firebirdsql.org
从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比，关于性能问题：
http://www.jbxue.com/db/6334.html
SQLLite操作百万级数据之优化篇
描述:SQLite数据库本质上来讲就是一个磁盘上的文件，所以一切的数据库操作其实都会转化为对文件的操作，而频繁的文件操作将会是一个很耗时的过程，会极大地影响数据库存取的速度。
描述:
SQLite数据库本质上来讲就是一个磁盘上的文件，所以一切的数据库操作其实都会转化为对文件的操作，而频繁的文件操作将会是一个很耗时的过程，会极大地影响数据库存取的速度。例如：向数据库中插入100万条数据，在默认的情况下执行相应的操作,就会打开和关闭文件100万次，所以速度当然会很慢。
分析:
在入库和更新过程中按照数据库事务的思想进行设计：SQLite执行入库、更新操作的方式是，语句执行对象句柄调用库函数打开文件、调用函数执行sql语句、关闭文件。这样的执行方式对于数量级别超大的文件的弊端就是每次执行sql语句的时候都要打开文件（假设百万级数量级的数据，就要打开和关闭文件百万次），对于数据库的入库和更新操作时间主要都浪费到了文件的打开和关闭操作上，所以这里增加事务以解决该问题.
解决:
SQLite数据库是支持事务操作的，于是我们就可以通过事务来提高数据库的读写速度。事务的基本原理是：数据库管理系统首先会把要执行的sql语句存储到内存当中，只有当commit()的时候才一次性全部执行所有内存中的数据库。同时,在.NET中对数据的操作还可以采用预编优化的方式来提升性能,这种方式是采用IDbCommand的Prepare方法来进行的。
示例:
以下引用网络上的一个示例数据来说明一下效果
引用地址:http://www.cnblogs.com/Kevin-moon/archive/2008/12/01/1344658.html
A、系统环境
OS：Windows XP Professional Server Pack 3
CPU：AMD K8 3200+(2.2G)
RAM：3G
HD：Seagate 160G IDE 7200RPM
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操作,可以进一步优化其性能。