Corss database - SQL Parser 過去愚蠢的想法

大約在去年的這個時期，接收到了一個任務，產品的改版開發！
其中一個主要的改版重點就是...要讓產品可以支援在不同的Database上面！

那時一直在考慮是否應該導入類似Hibernate這一類的O-R Mapping技術呢？
後來選擇了捨棄這樣的想法...主要有幾個原因，如下：

1.因為是由舊產品改版，所以想說可以沿用一些舊有的SQL
2.內部人員皆未有這方面的技術背景，學習成本以及開發時程，將會是一個風險
3.因為產品的Domain Knowhow，所以有很多極為複雜的SQL語法，要用Hibernate這類的寫法來完成，有許多瓶頸與困難度

基於這一些總總的理由，所以我們捨棄了它

但是我們又要如何達到跨DB的目標呢？
一個天真的想法，儼然而生...SQL Parser
先Focus在SQL Service上開發，然後所有的SQL語法皆會先丟到一個Parser內，產生各種不同DB的語法出來，再去執行...

這樣的想法似乎可行...

離開了這個產品的開發團隊快兩個月了...對於許多不同的DataBase，開始有了深入的研究與應用...
例如oracle、foxpro...等
當我知道的越多...我發現，要做出符合所有DB的Parser，是一件艱鉅的工程...
因為各家的語法，差異性真的非常非常的大~~
而且我們也因為這樣的想法，捨棄了很多DB Server獨有的語法...
讓我們必須在許多地方，捨棄了效能較好的語法或函式...
得不償失...

如果現在讓我重頭再來，我會考慮兩個方案...
1.直接選用O-R Mapping工具，把學習成本作為長期的投資
2.針對各種不同的DB開發不同的SQL語法(當然會將它作為可抽換的元件模組...)
雖然這樣在MA上，較為困難也複雜...但，我可以享受某些語法所帶來的便利與效能的優化...


離開自己一手開發的產品兩個月了...有許多的不捨...
有些時候雖然有些後悔...
但，我看到了更多不同團隊開發出來的產品，了解更多不同的開發架構...
有些東西我真的覺得，過去我們真的做的很好，
但也發現了，我們做了很多愚蠢的想法！
我思考著...如果再來一次，我會怎麼做...
如果這個專案是由我開發的，我又會怎麼做...
我想這就是一種成長、一種學習吧...

這個禮拜以來，我的MSN暱稱都是
if (me.today == me.yesterday) me.tomorrow = null;

這句話是我在一位技術書籍作者的Blog上看到的！相當有意思~~
分享給各位~~
也期勉自己，千萬不要讓這一個判斷式成立....