如果你爱一个人,就让他写SQL,因为那是天堂。
如果你恨一个人,就让他写SQL,因为那是地狱。
天堂,是因为他如此简单,又功能强大,可以极大简化你的程序。
地狱,是因为他如此纷繁,复杂,还有各种方言标准,而且不通用,当你试图切换数据库产品的时候,什么叫生不如死 ……
那我们就不能构建一个统一的数据库语言么?这个真不能,不是技术上不能,而是利益趋势,大家坚守自己的方言堡垒,而且越建越高。
ORM或许是解决这个问题的一个途径,正如其名,既然是对象关系映射,未免就会是一套机械、呆板的程序,我们只能将关系和实体映射出来,所以,这并非是解决问题的根本途径,但不能否认它确实是最受欢迎,使用最广泛,代价最小的方案,没有之一。
那我们是不是能从SQL语言翻译的角度来解决这个问题呢?即在将SQL抛给数据库执行之前,进行一次翻译工作?
我们可以对SQL进行语法分析,形成一颗AST(抽象语法树),然后遍历解析
我们在遍历语法树的时候,就进行一次翻译转换,形成其他方言的SQL。
这个方案也许不尽善尽美,但是至少解决了一个类似“同声传译”的问题。
对上述模型进一步演化,在AST层面进行双向转化,那这个实现是不是就看起来非常优雅了?
我们已经定制了一条看似合理的Roadmap,那么如何将其实现落地呢?
下表,是我对可完成上述任务的框架进行的一些总结
个人是十分推崇Calcite的,因为其本身更像是一个没有物理引擎的数据库引擎,这可能听起来有点滑稽,但是确实,他可以很好的解析SQL,并生成执行计划,如果你想,也可以针对其进行你希望的优化,这就让我们的控制力大大加强了,至少在数据库之上,就可以“为所欲为”了。
Durid提供的方言包,比较多,上手比较容易(文末附录里,贴出了一个查询的AST,结构还是挺清晰的),不过如果想达到AST层面的转换,对整套API需要进行一定的手术才行。
Antlr 可以说是非常强大的,他是单纯的语法解析工具,但是其语法文件比起javacc来,何止是平易近人,简直就是平易近人… 而且,shardingsphere,presto都是基于其开发的。在代码仓库里,也有很多线程的语法文件,可以使用,不过要达到上述目的,也需要走很长的路。
转载请注明:IT运维空间 » 运维技术 » 浅析构建SQL-to-SQL的翻译器
发表评论