再谈SQL-to-SQL翻译器

在前一篇文章中《浅析构建SQL-to-SQL的翻译器》，我简单的阐述整体的思想。很高兴借此认识了一些新的小伙伴，并且进行了深入的探讨。

今天我们再来做一些进一步的思考，然后再加入一点想象力，看看是否可以将深度学习引入到这个过程中来呢？接下来，我们就来说说吧。

常规

显而易见的，我们有几条路可以选，

1. 解析阶段转换

   即在源SQL输入进行语法解析的时候，同时构建目标SQL的AST。
   

2. 遍历阶段转换

   即在遍历源AST的时候，构建目标SQL的AST。

3. 直接转换
   

        即直接将源AST硬转成目标AST。

在这里，我描述的尽量简化，但是实际上，我们都很难一次性完成转换工作，需要结合上下文进行相关的语义转换。而且我们可能在转换过程中，需要构建一套“中立”的AST，用于抽象和存储各种SQL方言特性。然后再进一步转化。

我们以durid的parser为例，对ast api进行一些扩展，以存储上下文，以及记录转换变更，以便溯源。

NLP 

上面，我们介绍了一些常规手段，接下来就是我最近的一点思考，也是偶然读到了几篇关于NL2SQL的文章受其启发，所想到的。

NL2SQL(Natural Language to SQL)， 顾名思义，是将自然语言转为SQL语句。它可以充当数据库的智能接口，让不熟悉数据库的用户能够快速地找到自己想要的数据。

既然NLP能做到自然语言翻译成SQL，为什么不能在 SQL-to-SQL 的翻译上做一些工作呢？

这方面，我们需要做的探索，目前我理解如下：

• SQL的分词和词性划分，与自然语句分词不同

• SQL的语法与自然语言不同。
  

• SQL-to-SQL 部分为强规则，部分需要理解执行语义

好了，今天就先写到这，欢迎有兴趣的同学和我交流。如果本文对你有一点点帮助，那么非常期望你能关注我，并转发。

参考链接

https://spaces.ac.cn/archives/6771

http://www.itongji.cn/detail?type=99991958

https://www.zhihu.com/question/24588198?sort=created

关注 【 麒思妙想】解锁更多硬核。

历史文章导读：

• 浅析构建SQL-to-SQL的翻译器
  

• 抽象语法树为什么抽象
  

• 基于Calcite自定义SQL解析器
  

• 基于JDBC实现VPD：SQL解析篇
  

• 如何成为一个成功的首席数据官
  

• 数据库深度研究（100页PPT）
  

• 基于Win10单机部署kubernetes应用
  

• 浅谈基于JDBC实现虚拟专用数据库（VPD）
  

如果文章对您有那么一点点帮助，我将倍感荣幸

欢迎  关注、在看、点赞、转发