我最早接觸的SQL資料庫是 Oracal DB,
當時有一種說法是.... Oracal 資料庫是最好的資料庫但也是最貴的資料庫,
(要花很多錢買的意思)
這件事在後來我轉到開始使用 sybase 資料庫時有了些許體驗,
因為在使用 Oracal 時覺得過程都沒有什麼特別的困擾, 但當相同的需求換到Sybase時卻語法不支援, 往往要用另外一種方式撰寫來達到相同的輸出目的.
(也有可能在使用 Oracal 的時侯因為工使用深度不深也有可能)
而在Sybase 時期則是每天都在和資料庫打交道也要寫 store procedure,因為用的深所以會發現它的限制和缺陷.
記得當時還沒有免費的 My SQL(或是尚不流行?),MSSQL 也不見蛋,
所以或許還有其它的選擇但 Sybase 確實是當時算起來好用且負擔得起費用很流行的資料庫。
在FOR Sybase的 SQL 語法眉角都熟了之後的感覺是雖然不管要做什事它都是做的到, 但有時會覺得某些地方用的很卡,
即明明某個需求可以直達卻要繞路, 但最後還是可以到目的地的.
當時時常會抱怨為什麼 Sybase DB 為什麼這裡不優化那裡不優化?
慢慢的也理解有些東西是一開始設計就決定好的架構限制,
如果要改善這種問題可能就是要從頭蓋這間房子才有辦法。舉例來說,
一開始蓋樓房蓋到10樓在當時可能是很了不起了, 隨著後來需求的發展又增加蓋了5樓, 但原始的電梯只能從1樓直達10樓, 如果建築師只能另外從11樓設置了一台電梯到15樓,
如果從一樓要到15樓, 不管你是誰就是要坐到10樓再轉乘另一台電梯的意思,
就這樣這棟15樓高的在房子, 也不是不能住, 也是有電梯, 就這樣用了下去.
但你可以想像有天你要搬個書桌或冰箱那麼重夠累了還要中途轉車, 搬進搬出的能不抱怨也難。
這點真的也不能怪 Sybase , 畢竟科技本來就是在進步, 人的需求只會成長, 就算是有理想一開始就有想像未來可能有15樓的房子但材料科學水準不夠時也還是個冒險, 再說了, 就想要蓋也會遇到現實會被打槍, 被批評都還不知道會不會有人買單就蓋那麼高的可能性也不能忽略....。.
就這樣在 Sybase 著實風光了幾年,
印象中資訊界沒沒的發生一件事, 就是聽說微軟將 Sybase 的資料庫技術開發團隊整個挖角轉去開發微軟自己的資料庫, 不久之後微軟突然之間就推出了現在 MS SQL的資料庫, 一開始也是鳥鳥的, 但感覺就是衝著 Sybase 而來的, 專門改善 Sybase DB 的痛點來開發, 而且它改版的很快. 沒多久我就一點都不想用 Sybase DB了......
關於 MSSQL 我的使用經驗就是....一整個暢快,那些原本卡點幾乎都改善了, 包括備份和還原的流程.
想想這也是理所當然的事,
假設我是原本 Sybase DB的開發團隊, 這個房子是我一手蓋起來的, 它有什麼優缺點, 屁股有幾根毛我還能不知道嗎? 那些限制身為開發者應該也很想整棟推平重蓋一棟「完美的大樓」微軟的給了這些開發團隊一個舞台也為自己生出了金雞蛋, 想想(微軟)有錢真的好辦事! 在當時....那就是一件有錢就能搞定的事, 畢竟人才都在 Sybase 那裡, 錢能解決的事就不要麻煩了, 把有限的心力花在有錢也不好處理上的事情才是聰明!
這些年 Sybase 資料庫愈來愈少被看見, 可惜的是現在的我沒有什麼機會在實務上回去使用 Orcal DB, 所以也蠻好奇以現在的我的體驗及理解去重看 Orcal 的DB 不知是否真的那麼好嗎? 或許在大量資料時才是他們決定性的關鍵因素, 但那應該又是另一個故事了, 至少我猜微軟也是有研究過定位這件事的, 消費者各取所需, 市場各自經營也是一種平衡未嘗不是好事。
你現在都用什麼資料庫呢? 有什麼感覺呢? 歡迎分享!
沒有留言:
張貼留言