<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>


    這是一個很老的問題了,經常在論壇上看到,很多人也寫了相關的文章。我在這方面擁有較多的經驗,我也談一下我的看法吧。

    我曾經實現過金蝶EAS BOS的多數據支持引擎,腳本引擎,也作過O-R Mapping的預研工作,曾經對多個O-R Mapping產品做過研究。

    C++、Java、C#都源自Algol,這系列語言也稱為Imperative語言,中文翻譯為命令式語言。命令式語言建立在馮*諾依曼體系結構上,程序員必須處理變量管理、變量復制。這樣的結果是增加了執行的效率,但帶來了程序開發的艱苦。

    LISP、Schema、Haskell等語言屬于函數式語言,函數式語言基于數學函數,不使用變量或者賦值語句產生結果,使用函數的應用、條件表示和遞歸作為執行控制。函數式語言是更高級的程序設計語言,和命令式語言相比,編寫更少的代碼,更高的開發效率,這是函數式語言的明確有點。很多編程技術都首先應用于函數式語言,例如范型、垃圾收集等。很多函數式語言都增加了一些命令式語言的特征,增加效率和易用性。

    SQL語言是一個領域專用語言,專門用于處理關系數據。他具備一些函數式語言的特征,在處理關系數據方面非常直觀和簡介。在處理選擇、投影、聚合、排序等等操作方面,顯然比在Java或者C#中要方便得多。SQL也是易學易用。很多非程序員都掌握SQL,在金蝶,大多需求人員都熟練掌握SQL。SQL的解釋需要損耗一定的性能,在對性能極端要求的情況下,通常不使用關系數據庫。例如Google Account采用Berkeley DB等。

    現在關系數據庫已經發展很成熟,數據庫的一些技術發展得很好,包括事務等,其中一些從數據庫中發展起來的技術,還應用到操作系統中了。在前些年面向對象技術狂熱的時候,作了很多面向對象數據庫的研究,但是都沒有取得較大的成功。在主流的關系數據庫中,大多都包括了面向對象的支持,例如Oracle、Sybase,都具備了很豐富的面向對象功能,但是很少任用。

    現在有人跟我說起db4o這樣的數據庫,我認為db4o不會取得成功,因為他在錯誤的方向發展。

    現在關系數據庫最流行,最流行的應用開發語言包括Java、C#等,都是面向對象命令式語言。開發語言需要訪問關系數據庫,需要轉換,轉換的過程比較繁瑣,于是就誕生了O-R Mapping技術。這是一種妥協的結果,面向對象技術在數據庫領域無法取得成功,在面向對象開發語言中,就需要一種對象-關系映射技術。我相信,這種妥協產生的技術,會越來越流行。

    我也認為,這是一個正確的選擇。就如高級語言不會嘗試取代匯編,無論高級語言有多好,最多在其上增加抽象層。例如Java使用bytecode、C#使用IL這樣,使用一種抽象層,而不是嘗試取代匯編。

    O-R Mapping技術除了簡單映射之外,需要一種OQL,混合SQL和面向對象特征,提供映射方便的同時,保留關系數據庫提供的強大功能。例如聚合、排序等關系運算必須在OQL中提供。由于程序中的返回結果,有時不需要映射成對象,所以OQL必須提供另外一種功能,數據查詢。很多O-R Mappping產品都提供了基于對象的OQL和基于數據的OQL。

    這導致包括三個部分:
    1、應用程序使用OQL
    2、O-R Mapping解釋或者編譯OQL
    3、對象數據庫負責數據處理

    如果O-R Mapping使用解釋的方式處理OQL,則會包括產生SQL、組裝對象等操作。效率通常都不會很好,現在的O-R Mapping產品基本都是基于解釋的方式處理。

    如果O-R Mapping使用編譯的方式,可以優化產生SQL,動態創建SQL存儲過程,減少SQL交互的過程,能夠獲得很好的性能,可以做到比絕
    大多數人直接使用SQL性能都要好。我曾經做過一個實驗性的實現,取得很好的效果,可惜由于種種原因,沒有繼續下去。

    我認為,下一代的O-R Mapping產品,都將會采用編譯的方式,因為在很多情形下,特別是復雜對象的處理方面,可以有大幅度的性能提升,在某些場景下,可以數倍甚至數十倍的性能提升。

    一直不是很看好Hibernate,因為其主要作者gavin對編譯技術不了解,2.x版本的HQL語法很搞笑,實現也是很搞笑的,簡單的文本替換,看到讓人目瞪口呆。3.0之后加入了HQL的AST(抽象語法樹),但這不是他本人的做的,其他愛好者加入進來,3.1還是沒有很好融合進來。之后的版本我就沒有繼續關注了。

    我覺得O-R Mapping完全就是一種編譯技術,不懂編譯技術的人去作這件事清總會有些不妥。這不單是Hibernate的問題,也是其他O-R Mapping產品的問題。


    我的觀點:
    1、Java、C#、C++等語言在處理關系數據方面沒有優勢。SQL是關系數據處理的領域專用語言(DSL),更適合處理關系數據,提供強大的功能。
    2、關系數據是主流,希望應用開發人員使用O-R Mapping,而不懂關系數據庫,這是不現實的。
    3、O-R Mapping技術還有很大發展空間,以后在功能、性能等方面都會有重大提升,最終成熟。


    溫少 2007-04-23 08:18 發表評論

    文章來源:http://www.cnblogs.com/jobs/archive/2007/04/23/723297.html
    posted on 2007-04-23 08:23 溫少的日志 閱讀(1173) 評論(2)  編輯  收藏
    Comments
    • # re: 對象關系技術的探討
      CowNew開源團隊
      Posted @ 2007-04-23 09:49
      又見溫大俠發表文章了,支持一下。
      對你的說法表示一點自己的看法“O-R Mapping完全就是一種編譯技術,不懂編譯技術的人去作這件事清總會有些不妥?!保鋵峯rm中也并不是全部用的編譯技術呀,我感覺只有oql和多數據庫支持這塊才會用到編譯技術,而且Hibernate這樣的產品是開源的,有開源界無數的大牛為止奮斗,所以gavin不懂編譯技術也不是什么大的問題。
      很佩服你寫的KSQL,崇拜之極。  回復  更多評論   
    • # re: 對象關系技術的探討
      azure
      Posted @ 2007-04-24 18:47
      鄙人也一直不喜歡用什么o-r mapping,有強大靈活的sql工具,而且o-r mapping也不過是把sql做了一個封裝,底層還不是sql實現的。把自己平臺的sql做一個優化,比再學習什么HQL語言劃算多了,不用去理解什么n-n,1-n之間的復雜關系了。  回復  更多評論   

    只有注冊用戶登錄后才能發表評論。


    網站導航:
     
     
    主站蜘蛛池模板: 亚洲嫩草影院在线观看| 中文字幕亚洲无线码| 亚洲黄色网站视频| a级成人毛片免费视频高清| 亚洲AV无码成人精品区大在线| 免费v片在线观看视频网站| 国产精品亚洲а∨无码播放| 中文字幕版免费电影网站| 亚洲日韩一页精品发布| 亚洲乱码av中文一区二区| 男女午夜24式免费视频| 久久亚洲精品中文字幕无码| 国产va在线观看免费| 亚洲高清在线mv| 四虎国产精品免费久久| 亚洲狠狠婷婷综合久久蜜芽| 国产成人免费手机在线观看视频| 五月天婷婷免费视频| 亚洲综合熟女久久久30p| 99在线热视频只有精品免费| 亚洲精品自在线拍| 成人免费一区二区三区在线观看| www国产亚洲精品久久久| 一区二区在线视频免费观看| 国产精品亚洲成在人线| 999国内精品永久免费视频| 亚洲熟伦熟女专区hd高清| 青青青国产色视频在线观看国产亚洲欧洲国产综合 | 久久久久亚洲AV片无码下载蜜桃| 亚洲精品视频免费在线观看| 亚洲变态另类一区二区三区 | AV激情亚洲男人的天堂国语| 久久精品国产亚洲AV不卡| jzzijzzij在线观看亚洲熟妇| 亚洲午夜无码片在线观看影院猛| 18禁超污无遮挡无码免费网站| 亚洲一卡2卡4卡5卡6卡在线99| 免费一级国产生活片| 无码精品一区二区三区免费视频| 亚洲一区中文字幕| 亚洲无人区午夜福利码高清完整版 |