Firebird一款很牛X的数据库

Borland InterBase和开源的FireBird是一个强大的、支持SQL语言的数据库, 她常常用于嵌入式开发和特定的应用软件中。聪明的开发者和架构师花些时间详细的了解下IB/FB就会发现，她确实有多处超越MSSQLserver的优点。这些优点包括： 在混合读写环境下更加卓越的并发性； 更灵活的触发器支持； 更快的灾难恢复； 更简单的事件管理； 更多的部署选择； 跨平台支持； 小巧； 系统要求更低； 更短的培训时间； 更低的培训费用； 更低的许可费用；(FireBird彻底免费)

本文将详细讨论这些优点。 今天的嵌入式和分布式数据库应用创造了一种环境——由短期的读事务和更新事务 (典型的如数据录入系统)以及长时间读事务(如制做报表和数据分析)这两种状况组成。当数据分析要求立刻在此刻获得一个一致的数据视图时，MSSQLServer必须加锁来防止其余用户存取正在分析的数据。 IB/FB的数据库引擎专门设计成可以及时的为你的数据提供一个一致的快照，而不会阻塞其余用户的读和更新。在IB/FB中，读操做毫不会阻塞写操做，写操做只有当两个事务试图在同一时刻更新同一行时阻塞写操做。另外，IB /FB的并发模型是彻底可预测的。使用IB/FB，毫不会有MSSQLServer里相似锁的任意升级致使整个表的存取被拒绝麻烦。 IB/FB 拥有嵌入式或须要远程部署的应用所须要的全部关键特性。 你的开发团队很容易学习和使用，很容易部署且在产品中几乎不须要维护。IB只有只有MSSQLServer最小安装大小的六分之一(FB更小)，却提供了 SMP支持，跨平台支持，先进的基于成本的查询优化，行级锁，从服务器灾难中即时恢复，事务支持在任什么时候刻及时提供一致快照的隔离级别，丰富的SQL方言，before和after两种触发器，完整的触发器触发顺序控制，存储过程，在线备份，在线修改元数据，复制，以及在客户端的应用程序中触发来自数据库触发器的事件。 IB在三方面下降项目中的成本： 一、IB的受权许可费用比MSSQLServer低(FB是彻底免费开源的)； 二、须要更少的时间培训。一个MSSQLServer2000的DBA认证至少须要22天的课堂培训。 IB/FB学起来是如此容易以致于其培训课程只需5天，就可使一个彻底的数据库新手达到可以为IB/FB数据库提供信赖支持的程度。那些已经对基本的数据库管理熟悉的人会发现，不时查询一下Interbase的文档就是所须要的一切了。 三、开发人员没必要花时间寻找创造性的方法来写代码解决数据库的限制， 好比锁冲突，锁升级，缺乏的"before"触发器，有限的触发器触发顺序控制和须要的事件。

为你的项目选择合适的数据库 建一个你的数据库项目须要的属性列表不是难事。 但仅依靠一个简单的特性列表来评估数据库是不够的。为你的应用程序选择一个正确的数据库时最关键的一步是调查在你的应用程序将会遇到的真实情形中，你所考虑的数据库的行为。本文调查了IB和MSSQLServer在许多状况下的行为，在当今的商业环境中你颇有可能面对这些状况。

数据的一致性与并发性 假设你有一个存货管理系统，用于跟踪许多仓库中的产品条目。 在系统运行时，你的应用程序必需要出一个存货估价报表。使用读提交(read committed)的事务隔离，会发生下面的一系列事件： 一、开始一个将要合计价值的读事务，从各个仓库收集条目； 二、这个读事务扫描Abilene仓库的全部记录； 三、另外一个用户开始一个更新事物，从Abilene仓库移动1000金条到San Antonio仓库； 四、更新事务提交； 五、读事务读到San Antonio仓库的记录。这个读事务如今就把1000金条计算了两次， 一次在Abilene仓库，另外一次在San Antonio仓库。 在 MSSQLServer中，经过给读事务使用Serializable(连续读)事务隔离很容易避免这个问题。 Serializable隔离模式保护你的事务在其生存期内不会看到由其余用户做出的改变。然而，要达到这种效果，MSSQLServer要么锁住整个表，要么在WHERE语句跨越的全部覆盖值的索引上放一系列锁 (引自Microsoft SQL Server 2000, Microsoft Press,799页)。 虽然这些锁比表锁限制少，但仍有不少原本没必要要的行被禁止插入。考虑下面的SELECT语句： SELECT * FROM CUSTOMER WHERE CITY >= 'Charleston' AND CITY <= 'Los Alamos' 假设在CITY列的索引中覆盖的WHERE语句的范围是Abilene, Detroit, and San Francisco这些节点，那么这些节点都会被锁住。不幸的是，这将意味着你不能插入这样一列，它的值大于Abilene而小于Charleston，即便WHERE语句没有包含这一行，由于它在锁的覆盖范围内。一样的缘由，你也不能插入其值大于Los Alamos而小于San Francisco的行(引自Microsoft SQL Server 2000, Microsoft Press,776页 )。 虽然数据的一致性达到了，但这也牺牲了并发性， 由于其余用户不能在行锁覆盖的行及表锁覆盖的表上插入和更新的记录。当分析和汇总大量的数据时 ——好比上面的例子，在读事务结束以前，其余用户的插入和更新会一直被阻塞。 在IB/FB中，因为IB的版本引擎机制，这个问题根本就不存在。回到库存估价的例子中，下面是IB/FB的状况： 一、使用快照事务隔离机制，读事务开始； 二、读事务扫描Abilene仓库的记录； 三、另外一个用户开始一个更新事务，从Abilene移动1000金条到San Francisco； 四、更新事务发现一个更早的活动事务，因而为须要更新的记录建立新的版本； 五、更新事务提交； 六、读事务读到San Antonio中更新的记录。 读事务看到当前记录的版本是由一个在它以后开始的事务建立的，因而它往回扫描记录的版本，直到它发现一个在它开始时已经提交的版本，并读那个版本。 经过读那些只在读事务开始时已经提交的记录版本， 不用禁止记录的更新，IB/FB就能提供一个逻辑上一致的数据视图。

死锁 假如用户A执行一个SELECT语句读Parts表中的全部行。用户B也SELECT了Parts表的全部行。两个用户都要得到各自所选数据的一个稳定一致的视图。用户A试图更新part=100的记录。用户B试图更新part=101的记录。 MSSQLServer 会使用重复读或serializable事务隔离，这种状况将致使死锁，即便两个用户更新的是不一样的行。怎么会呢？A在读记录时获得表上的一个共享锁。B 也同样。当A更新part=100的记录时，必须获得这一行的排他锁，因而把他在表上的共享锁转换成意向排他锁。然而，意向排他锁和B的共享锁冲突，因此没法获得(引自Microsoft SQL Server 2000, Microsoft Press,799页 )。一样，当B要更新part=101的记录时，由于A的共享锁，B也不能把他在表上的共享锁转换成意向排他锁。这就是所谓的转换死锁(见 Microsoft SQL Server 2000, Microsoft Press,776页 )。 在IB/FB中不会发生锁转换。IB /FB只会在更新时锁住个别的行。IB/FB只会发生一种类型的死锁就是循环死锁(全部数据库都存在），也就是当用户A更新并锁住了行100，而后试图更新已经被用户B加锁并更新的行200，同时，用户B也试图更新已经被A加锁的行100。这种状况下，会发生下面两种状况之一。若是有用户在他们事务中指定了NoWait选项，那么当A试图给B已经锁住的行加锁时，会当即返回错误信息，反之亦然。若是两个用户都选择了等待加锁的行，那么锁管理器将检测到死锁并选择一个事务让其回滚。

锁冲突 考虑这样一种情形，当用户A对一行进行了更新操做但没有提交事务，而后A去吃午餐了。用户B执行一个包含此加锁行的SELECT操做。 使用MSSQLServer，用户B的事务将一直等待，直到用户A持有的锁释放为止(MSDN-Locking Architcture at http://msdn.microsoft.com/librar ... c/8_ar_sa2_2sit.asp )。“缺省设置下，没有强制超时期，也没有办法在加锁以前测试出释放的资源是否被锁，除非企图存取数据(潜在获得不肯定的阻塞)”(见Microsoft SQL Server 2000 Books Online, LOCK_TIMEOUT Setting)。“为了预防这种不肯定的等待，须要设置锁的超时期，使用SET LOCK_TIMEOUT命令，但这个设置会影响链接中全部事务”(见Microsoft SQL Server 2000 Books Online, SET LOCK_TIMEOUT)。 IB/FB限制更少且更灵活。使用快照事务隔离(snapshot)，你一直读的是事务开始时已经提交的行的最新版本。使用读提交(read committed)事务隔离，IB/FB给你三种选择： 一、读这一行最新提交的版本即便有未提交的版本存在； 二、等待，直到未提交的版本也提交或回滚，而后读这一行； 三、当即接收到一个异常警告：存在此行的一个未提交版本； 这些设置在事务级别，所以同一链接中，你为某一个事务的所做的设置不会限制到你为其余事务的所做的选择。 锁升级 设想你正在开发一个订单录入系统。订单条目表会包含上百万条记录。你必须可以经过客户类型和销售地域中的条目为某一时期生成销售报表，报表必须基于一致的数据视图。生成年报表将在订单条目表中选择超过百万的记录。 “当一个事务超过升级上限时， MSSQLServer2000会自动升级行锁和页锁。好比，当一个事务须要表中的一些行时， SQLServer自动得到这些行的锁，并在包含那些行的页、表或索引上放置更高级别的意向锁。当事务持有的锁的数量超过其极限时，SQLServer会企图把表上的意向锁变为更强的锁(如意向排他锁转为排他锁).得到更强的锁后，全部此事务持有的页级和行级锁被释放，锁开销减小了。”(见http://msdn.microsoft.com/librar ... c_8_con_7a_5ovi.asp, Lock Escalation )锁升级的结果是整个表对其余用户再也不可用。在本例中，记录上的共享锁将升级为一个表上的共享锁。因而其余全部用户都不能更新此表中的任一行。若是要更新一个表中的大量行，那么更新须要的排他锁可能升级为表级锁，以防止其余用户读和更新这张表。 IB/FB的版本体系结构在读记录时不须要任何锁。经过记录的不一样版本，一致性的数据视图不须要放置锁，更不会阻塞其余更新操做。IB/FB的锁只是行级别的，且只在更新一行时存在，因此根本不存在锁升级的概念。

触发器的灵活性 当给数据库添加新客户时，系统必须自动指定其销售区域和销售表明。为了指定正确的销售区域，应用程序必须从State表中查找用户所在的州，而后用销售区域和客户的分类代码查找Sales Rep表。理想的解决方案是给Customer表添加一个Before Insert触发器， 在记录插入Customer表以前添加销售区域和销售表明号码。 MSSQLServer没有在事件以前激活的触发器，只能附在 INSERT,UPDATE或DELETE事件以后激活(见Microsoft SQL Server 2000, Microsoft Press,657页)。 为了解决上面提到的问题，可使用所谓instead-of触发器。这种触发器激活后取代它所附属的事件。在本例中，将激活这种触发器，但那条新的客户记录不会被插入到数据库中。所以，触发器不只要决定销售区域和销售表明，还要执行把新客户记录插入数据库中的INSERT语句。这使得触发器很复杂，时间也浪费在写触发器上了。 更不幸的是，instead-of触发器还有其余限制。每一个事件只能有一个instead-of触发器。不能用多个触发器来模块化你的代码，以便容易维护。Instead-of触发器也不能和某些外键一块儿使用——这些外键给触发器所依附的事件设置了级联选项。好比，若是某个表有一个设置了级联删除的外键，instead-of触发器就不能出如今这个删除事件中。 IB/FB给INSERT,UPDATE和DELETE同时提供了before与after触发器。每一事件的触发器数量没有限制，在触发器和外键约束之间也没有任何冲突。 同一事件的多个触发器能使代码模块化，便于测试和维护。然而，对于触发器执行的顺序，MSSqlServer只提供了颇有限的控制。你能指定某一触发器第一个触发或最后一个触发，但仅此而已。一旦触发器必须独立于触发顺序，那么它们写起来很复杂且不够灵活。 IB/FB能够制定触发器执行的精确顺序。在触发顺序的任一点，随时可以很容易的插入新的触发器。 对于MSSqlServer来讲控制触发器中的错误很难。一旦触发器在事件以后触发，撤销触发器执行的INSERT,UPDATE或DELETE操做的惟一方法就是回滚事务。因为一个致命错误或请求回滚事务，触发器内的回滚停止了整批SQL指令，而不只仅是那些由触发器作的修改(见Microsoft SQL Server 2000, Microsoft Press,687页)。 IB/FB中，若before触发器产生异常，以前发生 INSERT,UPDATE或DELETE将会停止。IB/FB也容许在触发器激活时建立指定的还原点(savepoint)。你能够随时回滚到任一还原点。好比，更新前(before)触发器中建立一个还原点，而后在更新后(after)触发器中回滚到这个还原点，从而使该还原点后的所作的修改(包括触发此触发器的UPDATE自己)撤销了。不仅是在存储过程和触发器中，还原点在事务的任什么时候候均可用。

成本 应用软件也许分布在许多地方或支持许多用户，当使用到数据库时，数据库自己的许可费用会变为项目开支的一个重要部分。下面的表格比较了IB与MSSQLServer2000标准版的费用。IB在每一类中都更加实惠。 (注：由IB开源而来的FB是彻底免费且源代码公开的，即便在商业用途中，也是如此) 用户数 CPU个数 Borland InterBase MSSQLserver2000标准版 20 1 2300美圆(下同) 4498美圆(下同) 20 2 3300 4498 50 1 3700 4999 50 2 4700 9998 50 4 6700 11245 100或200 1 4199 4999 100或200 2 5199 9998 100或200 4 7199 19996

资源需求 减小部署费用的一个方法是经过网络发布你的应用软件。另外，你也许一样但愿能减小部署地点的硬件升级所需的开支。 MSSQLServer2000须要“97到270兆的可用硬盘空间，典型安装须要250兆”。Windows2000下须要64兆内存，WindowsXP下须要128兆内存。(见http://www.microsoft.com/sql/evaluation/sysreqs/2000/default.asp) IB彻底安装须要不到40兆的硬盘空间。若是你不安装文档和例子，那么安装少于15兆（FB所需更少）。此外在全部平台下，运行IB只须要32兆的内存。

部署与发布 你或许想把数据库服务器和客户端的安装集成到应用软件里，使安装部署更容易。 但你必须使用Microsoft提供的安装包来安装MSSQLServer。“SQLServer的安装程序写注册表，改变系统路径和多处系统设置，建立程序组和用户帐户，并为其使用执行基本的初始化配置。安装程序远非仅仅拷贝文件。对于你来讲，做为服务或产品的一部分建立本身的程序来安装 SQLServer是不现实的(见Microsoft SQL Server 2000, Microsoft Press,166-167页)。” 与之相比，IB/FB给了你彻底的灵活性。你可使用自己的安装包，也能够用其余安装打包软件，或者干脆本身写安装程序。

MSDE 也许，做为使用MSSQLServer的另外一种选择，你会考虑使用MSDE来部署发布应用程序。 MSDE就是SQLServe2000，拥有其全部特性和限制。MSDE还有三个额外的限制。“为了达到最佳性能，有一个限制在五个并发工做量的并发量管理器”， “若超过五工做量的限制，并发管理器会使系统不断的慢下来”(见http://www.microsoft.com/sql/msde/productinfo/features.asp)。每一条工做量是一个链接，若是每个用户须要两个链接，那么MSDE就只能支持两个用户。MSDE须要44兆的硬盘空间，2000下64兆内存，XP下128内存。(见http://www.microsoft.com/sql/evaluation/sysreqs/2000/default.asp) “MSDE支持2G如下的单个数据库。”——注意不是每一个表。这是第二个额外限制。这也就是说你的全部数据，元数据，索引，临时表，存储过程和触发器加一块儿必须在2G之内。 “MSDE2000包括一些供管理实例的命令”(见http://www.microsoft.com/sql/msde/productinfo/features.asp) ——MSDE不提供任何MSSQLServer的GUI工具来设计和建立数据库，管理服务器，测试查询和调整服务器的性能。 “几个Microsoft的产品有权许可转让使用和从新发布MSDE2000”(见http://www.microsoft.com/sql/msde/productinfo/features.asp) 得到的这些权力很复杂，并且依赖你购买的得到MSDE2000的Microsoft产品。有些产品不包括从新发布的权力。其余能从新发布的须要知足多方面的条件。

特性 下面的表格比较了IB/FB和SQLServer的特性。这个表单并不彻底，可是集中了重要的特性，如远程部署的嵌入式应用、长时间读事务间杂着更新事务组成的应用。 特性 InterBase/FireBird SQL Server 事务支持 是 是 SQL支持 是 是 用户自定义函数 是 是 基于成本优化 是 是 提供不会阻塞更新的一致数据快照 是 否 行级锁 是 是 不存在锁升级 是 否 不存在转换死锁 是 否 快照事务隔离 是 是 两段式提交 是 是 支持多用户和单用户 是 是 支持SMP 是 是 存储过程 是 是 before触发器 是 否 after触发器 是 是 触发器触发顺序控制 是 否 触发客户端事件 是 否 自动生成键 是 是 支持全部数据类型取空值 是 是 参照完整性 是 是 在线备份 是 是 在线更改元数据 是 是 复制 是 是 即时灾难恢复 是 否 零维护 是 是 定制安装包 是 否 内存须要 32MB 2000下64MB，XP下128MB 硬盘空间 40MB(包括文档和例子)，不然不到15MB 平均250MB

结论 IB/FB是你拥有： 混合读写环境中卓越的并发性； 更灵活的触发器支持； 更快的灾难恢复； 更容易的事件管理； 更多的部署选择； 跨平台支持； 小巧； 系统要求更低； 更短的培训时间； 更低的培训费用； 更实惠的许可费用... IB/FB以最低的成本和最短的时间，提供了建立强大应用所须要的特性。

做者简介：Bill Todd是Database Group, Inc.(Phoenix旁边的一个数据库咨询与开发公司)的总裁。合著过4本数据库编程方面的书籍，发表超过100篇文章。在美国和欧洲的开发者大会上提交了超过20篇论文。