如何运用设计模式实现Sql语句动态转换？

由于系统面向客户的实际情况不同，对数据库的选择上，有的偏向于Sql Server的易用性和可维护性，有的偏向于Oracle的健壮性和稳定性，而现有代码中Sql语句都大量应用服务器端的函数和关联(Oracle)，这些函数调用的名称、参数等在这不同数据库中有很大的差别。如果为每种数据库去维护一份代码，将来的维护成本将会越来越高；如果要有功能的升级，对代码的修改量将是几何级数的增加。

对于这个问题，开始的设想比较简单，在执行Sql语句前，首先检查当前所连接的数据库，如果是Oracle则不作任何干涉，如果是连接SqlServer只要把Sql语句中不相同的关键字和函数名替换掉，如Oracle中的To_Date换成SqlServer的Convert，就可以在SqlServer上执行了，对一些简单的Sql语句这样确实可以，可是对系统中大量复杂报表的应用来说，Sql语句可能多层嵌套，函数也有多层嵌套，如果只是简单的替换，将会有无数的if else，并且出错后的修改和调试几乎是不可能的。
通过对Oracle和SqlServer两种数据库的Sql语法的研究比较，认为必须采用语法分析，把Sql语句解析为一棵语法树，然后再按照语法的转换规则把sql语句转换到SqlServer上可执行的语句。要实现这样的功能，需要用到的模式有：
1.INTERPRETER(解释器)—类行为型模式：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。通过实现解释器模式，把要执行的Sql语句解释为Sql的语法树。例如一个Select语句的结构如下

从这张结构图中可以看到，Sql语句可能出现非常复杂的组合结构，如果不使用语法树表示，很难实现不同数据库平台的转换。在系统中，调用Sql语句转换功能的是TAdoDataSet或TAdoQuery，也就是模式中的Client。所以运用该模式的类关系如下

2.COMPOSITE（组合）—对象结构型模式：将对象组合成树形结构以表示“部分-整体”的层次结构。C o m p o s i t e使得用户对单个对象和组合对象的使用具有一致性。

从上面的Sql语句的语法结构可以看到一个查询语句可能是很简单的select * from ATable，也可能在sql里面又包含其他的Sql语句。按照组合优先于继承的规则，并没有给单独的Sql和复合的Sql语句创建不同的类，而是在内部组合并递归引用自己的定义，对访问语法树的客户代码来说，并不需要了解所访问的Sql语句是否存在复合结构。


3.VISITOR（访问者）—对象行为型模式：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。前面已经通过解释器模式解析Sql语法，用组合模式来存储解析的语法树，但是我们所需要的不仅如此。还要按照SqlServer的语法结构把语法树上的各个节点重新组合，最终输出SqlServer上可以执行的Sql语句。例如：Oracle中的一句连接查询select a.*,b.* from a,b where a.id=b.id(+),在SqlServer中对应的语句应该是select a.*,b.* from a left join b on a.id=b.id。从这个简单的例子中可以看到对于表的左连接或右连接，两种数据库的语法结构存在较大的差异。如果是在TSql类中写某个方法，由这个方法遍历语法树上的每个节点，并按照SqlServer的语法结构组合所需要的结果，是可以达到这个目的的。可是如果需要从这棵语法树导出其它数据库上如sybase可执行的sql语句呢，那又要在TSql类中再增加新的遍历算法，所有的相关代码又要重新编译。通过采用访问者模式，把遍历节点时组合语法树节点的算法封装再访问者的方法中，如SqlServer的语法就是一个TSqlServerVisitor类，语法树遍历每个节点时，都会调用它的Visit方法，全部访问完后即可通过GetSql得到所需要的Sql语句。这时如果我们需要转换到Sybase，只需要再实现一个TSybaseVisitor类，并传给语法树，就可以得到sybase的sql语句了.