Informax.SqlCenter跨数据库平台（一）——简介

   在大中型企业应用开发中经常会涉及到跨数据库平台的问题，也就是说需要产品能够在多种DBMS中正常运行。但是由于各种DBMS之间存在着很多差异，使得开发出来的程序在进行数据库平台移植的时候变成了一个非常令人头疼的问题。
    在通常情况可以通过为每一种数据库开发一个DataAccess程序的方法，只要实现相同的接口也可以时间数据库平台的移植。但是这种方法的可移植性是非常有限的，而且实施起来难度也是非常高的，唯一的优点就是在程序运行的时候效率会比较高。下面是这种架构的基本结构图。
 
在使用这种架构的时候如果需要增加对新数据库（例如SyBase）的支持的情况下，就需要为这种数据库再开发一个数据访问层，如果业务逻辑出现错误的话，面向每一种数据库的DataAccess层都需要进行相应的修改，但在大多数情况下都在重复的劳动。这就在架构设计上无形增加了项目的维护难度。
    同样为了解决跨数据库的问题，出现了另外一种设计架构。如下图所示

在第二种架构中，DBMS PersistBroker是整个项目的基础，因此有着举足轻重的重要性。为了完成这个部分我设计并实现了Informax.SqlCenter组件（由于时间仓促还没有来得及进行详细的测试），当前已经内置了对五种数据库（Sql Server, Oracle, DB2, MySql5, InterBase）的支持，能够实现在这个组件的基础上完成的程序在这五种数据库平台上进行无缝平移。当然为了实现可移植性需要根据SQL-92来实现基本功能同时舍弃大部分各种数据所特有的属性。基本的结构图为

现在介绍一下这个组件的主要特性：

1. 多数据库支持。
       开发此组件的主要目的就是为了支持多种数据库，但是要求DBMS具有事务管理、存储过程、子查询等功能，而且这些功能也是大中型软件开发中最基本的需求。例如MySql4, Microsoft Access, Foxpro等DBMS就不会被此组件支持，这是因为这几种DBMS不支持这三种功能。而在实际开发中有几种完全支持这三种功能的DBMS已经在组件内置了驱动，它们分别是Microsoft Sql Server 2000, Oracle, DB2, MySql5和InterBase。
2. 数据库驱动扩展支持。
       当然已经内置的五种数据库驱动虽然能够大多数需求，但并不能完全满足所有的需求，在很多的情况下并不是在这几种数据库环境下进行开发和实施的，因此就产生了对这几种数据库驱动程序之外的数据库驱动支持的需求。为了解决这个问题我们可以通过现有的扩展接口实现对新的DBMS的支持就可以完成驱动的二次开发，而当前需要进行扩展的结构已经进行极大的简化处理，一般的情况下进行扩展开发的时候只需要继承PersistBroker和SqlGenerator并实现相应的函数就可以了。
3. SQL函数的扩展支持。
       在SQL函数的扩展性问题上存在两个纬度的扩展性——新增SQL函数的扩展，相同SQL函数在不同数据库环境下的扩展支持。为了解决这个问题，在这个组件中使用了"函数解析器中心引擎"的方法，采用策略模式来实现函数的解析，对于每一个函数都提供了一个默认的函数解析器（依据默认代理模式）从而在进行扩展的开发时不需要为每一个函数都实现与数据库相应的解析器，而只需要在默认解析器不满足当前数据库环境的情况下为这个函数实现一个相应的解析器。对于新增SQL函数的情况，只需要从SqlFunction继承并实现新的SQL函数同时并实现函数解析器就可以完成了。但是建议在现有功能能够满足使用的话不要新增SQL函数，这是因为在SQL-99标准之外的函数并不被当前所有的DBMS所支持，只有在确定您的所有实施环境中的DBMS能够直接或者间接支持这种函数的情况下才不会产生程序移植的问题。
4. Top功能的支持
       在这个功能上很多开发多数据库支持组件的作者都会感到困惑。这是由于Top关键字只有在SQL Server中提供了支持并且进行了优化，因此在使用Top的情况下可以提高程序的执行效率，同时也可以满足很多特殊的需求（例如分页查询）。但是这种功能和效率并不是在所有的数据库中都具备的，因此在实现这个功能的时候只能够保证没有逻辑的错误，而不能够完全的保证高效查询的功能（例如Oracle只能使用嵌套查询的方法实现，因此同样需要进行全表扫描）。虽然这个功能没有在SQL-99中有相应的规定，但是已经在各种数据库服务器的开发中进行了默认的支持，只不过支持的方式不同而已。也正是由于这个原因，在进行SQL解析器的二次开发时需要为每种DBMS对选择查询实体的解析提供不同的实现方法。

使用这种架构不仅可以解决在各种数据库系统上移植的问题，同时也可以解决同一个业务需要重复维护多个程序集的问题。但是缺点并不是没有，最主要的就是效率可能会相对低一点，经过测试在执行相同的查询语句的时候这种方法会多耗费几十毫秒的时间，但是这个时间是完全可以忽略的。另外的一个问题就是PersistBroker层的开发难度和测试难度都是比较高，同时也是非常严格的。因此需要经过长期的摸索和尝试才能设计出合理的架构和程序。