[[356455]]

如果你愛(ài)一個(gè)人，就讓他寫(xiě)SQL，因?yàn)槟鞘翘焯谩?/p>

如果你恨一個(gè)人，就讓他寫(xiě)SQL，因?yàn)槟鞘堑鬲z。

天堂，是因?yàn)樗绱撕?jiǎn)單，又功能強(qiáng)大，可以極大簡(jiǎn)化你的程序。

地獄，是因?yàn)樗绱思姺?，?fù)雜，還有各種方言標(biāo)準(zhǔn)，而且不通用，當(dāng)你試圖切換數(shù)據(jù)庫(kù)產(chǎn)品的時(shí)候，什么叫生不如死 ......

那我們就不能構(gòu)建一個(gè)統(tǒng)一的數(shù)據(jù)庫(kù)語(yǔ)言么?這個(gè)真不能，不是技術(shù)上不能，而是利益趨勢(shì)，大家堅(jiān)守自己的方言堡壘，而且越建越高。

ORM或許是解決這個(gè)問(wèn)題的一個(gè)途徑，正如其名，既然是對(duì)象關(guān)系映射，未免就會(huì)是一套機(jī)械、呆板的程序，我們只能將關(guān)系和實(shí)體映射出來(lái)，所以，這并非是解決問(wèn)題的根本途徑，但不能否認(rèn)它確實(shí)是最受歡迎，使用最廣泛，代價(jià)最小的方案，沒(méi)有之一。

那我們是不是能從SQL語(yǔ)言翻譯的角度來(lái)解決這個(gè)問(wèn)題呢?即在將SQL拋給數(shù)據(jù)庫(kù)執(zhí)行之前，進(jìn)行一次翻譯工作?

我們可以對(duì)SQL進(jìn)行語(yǔ)法分析，形成一顆AST(抽象語(yǔ)法樹(shù))，然后遍歷解析

我們?cè)诒闅v語(yǔ)法樹(shù)的時(shí)候，就進(jìn)行一次翻譯轉(zhuǎn)換，形成其他方言的SQL。

這個(gè)方案也許不盡善盡美，但是至少解決了一個(gè)類似“同聲傳譯”的問(wèn)題。

對(duì)上述模型進(jìn)一步演化，在AST層面進(jìn)行雙向轉(zhuǎn)化，那這個(gè)實(shí)現(xiàn)是不是就看起來(lái)非常優(yōu)雅了?

我們已經(jīng)定制了一條看似合理的Roadmap，那么如何將其實(shí)現(xiàn)落地呢?

下表，是我對(duì)可完成上述任務(wù)的框架進(jìn)行的一些總結(jié)

個(gè)人是十分推崇Calcite的，因?yàn)槠浔旧砀袷且粋€(gè)沒(méi)有物理引擎的數(shù)據(jù)庫(kù)引擎，這可能聽(tīng)起來(lái)有點(diǎn)滑稽，但是確實(shí)，他可以很好的解析SQL，并生成執(zhí)行計(jì)劃，如果你想，也可以針對(duì)其進(jìn)行你希望的優(yōu)化，這就讓我們的控制力大大加強(qiáng)了，至少在數(shù)據(jù)庫(kù)之上，就可以“為所欲為”了。

Durid提供的方言包，比較多，上手比較容易(文末附錄里，貼出了一個(gè)查詢的AST，結(jié)構(gòu)還是挺清晰的)，不過(guò)如果想達(dá)到AST層面的轉(zhuǎn)換，對(duì)整套API需要進(jìn)行一定的手術(shù)才行。

Antlr 可以說(shuō)是非常強(qiáng)大的，他是單純的語(yǔ)法解析工具，但是其語(yǔ)法文件比起javacc來(lái)，何止是平易近人，簡(jiǎn)直就是平易近人... 而且，shardingsphere，presto都是基于其開(kāi)發(fā)的。在代碼倉(cāng)庫(kù)里，也有很多線程的語(yǔ)法文件，可以使用，不過(guò)要達(dá)到上述目的，也需要走很長(zhǎng)的路。

本文轉(zhuǎn)載自微信公眾號(hào)「麒思妙想 」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系麒思妙想 公眾號(hào)。