迁移到MySQL有很多原因,在基础准备工作中,源库的建表语句到MySQL建表语句的转换,不仅涉及到数据库间的语法,数据类型等差异,同时在SQL开发规范方向也有一些相应的规范,如何提高开发效率,同时使得开发规范更容易落地,向MySQL迁移的语法转换工具的作用就尤为重要。
以下仅以SQL Server作为参考,对于Oracle等其他商业数据库也可以采用类似的处理方式。
经过调研分析和使用经验,计划支持两种使用模式。
模式1:指定数据库表
其中数据库的库,表,字段等元数据信息存储在运维系统元数据中,需要周期性和线上环境做字典信息同步,在接受到前端请求之后,提供一键转换接口,在这个处理过程中实现如下两个步骤:
1)构建出SQL Server侧的建表语句,该建表语句可以供前端显示和转换为MySQL语法作为参考。
2)将语句转换为符合MySQL基本规范的SQL语句,主要涉及数据类型,默认值,存储引擎,自增列值,字符集等。
在语法转换完成后,可以使用已有的SQL审核服务进一步审核修正,直至满足自动化上线的标(比如SQL打分为80分以上即可实现自动化上线)
模式2:输入SQL文本
输入SQL文本目前存在两类通用问题:
1)目前业务方使用的客户端工具存在差异,create table语句转换会生成两种风格的建表语句,第一类是create table xxxx,只有一条语句,第二类是:create table xxxxx,alter table xxxx add xxx;会有多条SQL语句
2)输入文本转换为MySQL文本的过程中,因为前端输入信息的差异在解析实现中复杂度较高。
在执行SQL文本时,会将SQL执行在虚拟数据库上面,执行完成后会同步推送SQL Servre侧的字典数据到运维系统的临时元数据存储中,然后在这个基础上,提供一键转换接口,在这个处理过程中实现如下两个步骤:
3)构建出SQL Server侧的建表语句,该建表语句可以供前端显示和转换为MySQL语法作为参考,此时建表语句会整合为独立的1条SQL.
4)将语句转换为符合MySQL基本规范的SQL语句,主要涉及数据类型,默认值,存储引擎,自增列值,字符集等。
在语法转换完成后,可以使用已有的SQL审核服务进一步审核修正,但是没有对接SQL自动化上线流程。
整个一套体系下来,需要设计哪几个接口,哪些是对内对外的服务就一目了然了。