喜欢一个人，就让他写SQL吧，因为那是天堂。如果你讨厌一个人，就让他写SQL，因为那太糟糕了。天堂，因为它是如此简单，却又如此强大，它可以极大地简化您的程序。妈的，就因为它太多样化了，太复杂了，还有各种方言标准，而且还不通用，当你试图切换数据库产品的时候，生不如死……那我们就不能建立一个统一的数据库语言吗？这确实是不可能的，不是技术上不可能，而是利益的趋势。每个人都坚守着自己的方言堡垒，越建越高。ORM可能是解决这个问题的一种方法。顾名思义，既然是对象关系映射，必然是一套机械死板的程序。我们只能映射关系和实体，所以这不是解决问题的方法。根本之道，但不可否认，它确实是最流行、使用最广泛、成本最低的方案，没有之一。那么能否从SQL语言翻译的角度来解决这个问题呢？也就是在把SQL丢给数据库执行之前，先做一个翻译工作？我们可以对SQL进行语法分析，形成一个AST（AbstractSyntaxTree），然后遍历分析，在遍历语法树的时候，进行翻译转换，形成其他方言的SQL。这个方案可能并不完美，但至少解决了一个类似于“同声传译”的问题。进一步演化上述模型，在AST层面进行双向转换，这样的实现看起来是不是很优雅？我们已经定制了一个看起来合理的路线图，那么如何实施呢？下表是我对可以完成上述任务的框架的一些总结，个人非常推荐Calcite，因为它更像是一个没有物理引擎的数据库引擎。这听起来可能有点搞笑，但确实，它可以很好的解析SQL，并且生成一个执行计划，如果你想，你也可以随心所欲地优化它，这大大加强了我们的控制力，至少在数据库上，我们可以“为所欲为”。durid提供了很多dialect包，入门也比较容易（文末附录贴了一个查询AST，结构比较清晰），但是如果要实现AST转换，需要对整个API集执行某些操作。好的。Antlr可以说是非常强大了。它是一个纯语法分析工具，但是它的语法文件比javacc更平易近人，简直平易近人……而且shardingsphere和presto都是基于它开发的。在代码仓库中，也有很多线程的语法文件可以使用，但要实现上述目标还有很长的路要走。本文转载自微信公众号“七丝妙香”，可通过以下二维码关注。转载本文请联系七思妙想公众号。
