Firebird数据库值得信赖吗？为什么我要在开发中选择它

　1、FireBird不是新手想象的那么弱，要想数据完整性好，速度快，连接数容量大，数据库大而不慢，还是FireBird是首选，用MSSQL是下策，至少目前MSSQL还达不到海量数据库标准，我的FireBird1.5和Interbase6完全胜任几百G的单数据库，应该是十万以上的连接数，当然，这个10万以上连接数是我服务器端程序来解决的，而十几个服务器端程序只用大概300多线程连数据库而已，客户的感觉一直就是查询真快。。。

根据经验，MSSQL的单数据库文件超过4G后，特别是含有各种索引，存储过程、触发器等复杂应用时，总会有些问题，做维护时很头痛的。当然，如果应用简单 ，记录数少，单记录尺寸大时，例如一般的信息管理数据，MSSQL还能支持大一点的数据库。若是记录数多，特别是读写密集型，如超市销售，省级销售网络，MSSQL基本玩完，硬撑是大幅增加维护成本，必须要上马FireBird了。

另外在大容量客户连接时，不管用什么数据库，千万不要用数据库原生的XML返回，XML是网络带宽杀手啊。最好用C的API返回记录集，再程序生成XML。

2、SQLite还是很鸡肋，真的不如全功能的嵌入式FireBird，网上的测试都是太简单，循环读写最简单的记录，我的测试是SQL语句只要稍复杂点，SQLite的速度可以说是慢，抛开复杂SQL语句不说，仅仅是循环插入BLOB字段，SQLite跟死了差不多，而Firebird依然是很欢快的。看来SQLite还是主要依赖 *** 作系统，还不能叫做数据库。

我以前每次做单机程序都会先选择SQLite，因为它能全编译进C++Builder，但每写一段时间都被迫换回Firebird，次次如此啊，真痛苦。最大的感觉是SQLite为什么总是那么不争气呢。。。

3、单单是为了速度的话，还是建议用BerkeleyDB，我做网络管理程序和数据库管理程序时，主程序都是用BerkeleyDB保存各种数据，它也能全编译进C++Builder，速度没得说。而服务器端数据库的用户信息、单位信息、产品型号标准等等变动少的表，我也是用BerkeleyDB做数据库的缓存表，一有客户端连接认证，直接查询发出即可，开发者更容易控制程序的运行稳定性，维护很少。

要看具体的sql脚本,因为很多的语句都是按照sql规范来设计数据库的,所以都遵循sql规范,文件的扩展名都是.sql,但是每个数据库都有自己的扩展.

这里你说的数据库文件究竟是指数据库的数据文件,还是存在于数据库中的建表,过程,触发器等数据文件,没有说清楚,因为前者可能不一样,但是后者一般都是.sql结尾的

对 PHP程序员来说，SQLite可以快速的搭建数据库开发环境，提供轻松、自容器、无配置、无独立服务的数据库环境，所有数据保存在一个文件里。当使用 MySQL 作为最终生产平台时，SQLite 是不可替代的开发环境解决方案。但真的没有其他兼容性更好的选择了吗？好吧，仅举几个原因：MySQL的兼容性和支持哈希索引，还不止这些！

当我们寻找 SQLite 的替代方案时，有两个可选，分别是 H2 和 MySQL Embeded 版本。我关注的是可像 SQLite 一样方便使用，但又必须兼容 MySQL。

下面我们对三个数据库进行简单的比较：

看似 H2 管理最简单，因此我在 PHP 下体验了 H2 后发现的一些限制：Quercus 的 MySQL 驱动无法和 H2 的 MySQL 兼容模式良好的工作，我必须使用 Quercus 的 PDO 驱动来替代。

MySQL Embedded 则是 100% 兼容 MySQL，我还没有开始测试。但也有一些不确定的问题，我不清楚是否可以分发包含 MySQL Embedded 的应用程序.

---