SQL翻译器下载：附件
对于这个问题，开始的设想比较简单，大致过程是:把Sql语句中不相同的关键字和函数名替换掉，如Oracle中的To_Date换成SqlServer的Convert，就可以在SqlServer上执行了.对一些简单的Sql语句这样确实可以，可是对复杂的应用来说，Sql语句可能多层嵌套，函数也有多层嵌套，如果只是简单的替换，代码中必然会有无数的if else，并且出错后的修改和调试几乎是不可能的。
通过对Oracle和SqlServer两种数据库的Sql语法的研究比较，认为必须采用语法分析，把Sql语句解析为一棵语法树，然后再按照语法的转换规则把sql语句转换到SqlServer上可执行的语句。要实现这样的功能，需要用到的模式有：
1. INTERPRETER(解释器)—类行为型模式：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。通过实现解释器模式，把要执行的Sql语句解释为Sql的语法树。例如一个Select语句的结构如下
从这张结构图中可以看到，Sql语句可能出现非常复杂的组合结构，如果不使用语法树表示，很难实现不同数据库平台的转换。
·3550 ACL配置举例·利用 Oracle 10g 技能学习 DB2 9.1·Cacls.exe修改文件访问权限·华为－中端产品QACL配置案例集·案例学习Oracle错误：ORA-12516·Sybase与Oracle的十二场性能比拼·Oracle数据导入导出imp/exp命令·JAVA连接Oracle的代码·案例学习Oracle错误：ORA-01631·Ruby on Rails之Oracle应用(1)
从上面的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语句了。
4.有限状态机--单词和关键字的识别.在解析一句sql语句前,先要把其中的字符、数字、关键字和函数等语法元素识别出来。这显然不能简单的用字符定位等来判断，而必须用状态机来识别不同的规则表达式。这方面现在c#里的规则表达式就很好用了。不过经过重写这些模式识别，也把以前学的编译原理好好复习了一遍，对有些概念的理解更深入一些，只怪当初学的还不够精啊。呵呵。
国外较成熟的sql翻译器参考：http://www.microsoft.com/downloads/thankyou.aspx?familyId=E35CEE88-C919-463F-B020-81468CD231DA&displayLang=en
http://www.ispirer.com/products