這是一個(gè)很老的問題了，經(jīng)常在論壇上看到，很多人也寫了相關(guān)的文章。我在這方面擁有較多的經(jīng)驗(yàn)，我也談一下我的看法吧。

我曾經(jīng)實(shí)現(xiàn)過金蝶EAS BOS的多數(shù)據(jù)支持引擎，腳本引擎，也作過O-R Mapping的預(yù)研工作，曾經(jīng)對(duì)多個(gè)O-R Mapping產(chǎn)品做過研究。

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

LISP、Schema、Haskell等語(yǔ)言屬于函數(shù)式語(yǔ)言，函數(shù)式語(yǔ)言基于數(shù)學(xué)函數(shù)，不使用變量或者賦值語(yǔ)句產(chǎn)生結(jié)果，使用函數(shù)的應(yīng)用、條件表示和遞歸作為執(zhí)行控制。函數(shù)式語(yǔ)言是更高級(jí)的程序設(shè)計(jì)語(yǔ)言，和命令式語(yǔ)言相比，編寫更少的代碼，更高的開發(fā)效率，這是函數(shù)式語(yǔ)言的明確有點(diǎn)。很多編程技術(shù)都首先應(yīng)用于函數(shù)式語(yǔ)言，例如范型、垃圾收集等。很多函數(shù)式語(yǔ)言都增加了一些命令式語(yǔ)言的特征，增加效率和易用性。

SQL語(yǔ)言是一個(gè)領(lǐng)域?qū)Ｓ谜Z(yǔ)言，專門用于處理關(guān)系數(shù)據(jù)。他具備一些函數(shù)式語(yǔ)言的特征，在處理關(guān)系數(shù)據(jù)方面非常直觀和簡(jiǎn)介。在處理選擇、投影、聚合、排序等等操作方面，顯然比在Java或者C#中要方便得多。SQL也是易學(xué)易用。很多非程序員都掌握SQL，在金蝶，大多需求人員都熟練掌握SQL。SQL的解釋需要損耗一定的性能，在對(duì)性能極端要求的情況下，通常不使用關(guān)系數(shù)據(jù)庫(kù)。例如Google Account采用Berkeley DB等。

現(xiàn)在關(guān)系數(shù)據(jù)庫(kù)已經(jīng)發(fā)展很成熟，數(shù)據(jù)庫(kù)的一些技術(shù)發(fā)展得很好，包括事務(wù)等，其中一些從數(shù)據(jù)庫(kù)中發(fā)展起來的技術(shù)，還應(yīng)用到操作系統(tǒng)中了。在前些年面向?qū)ο蠹夹g(shù)狂熱的時(shí)候，作了很多面向?qū)ο髷?shù)據(jù)庫(kù)的研究，但是都沒有取得較大的成功。在主流的關(guān)系數(shù)據(jù)庫(kù)中，大多都包括了面向?qū)ο蟮闹С郑鏞racle、Sybase，都具備了很豐富的面向?qū)ο蠊δ埽呛苌偃斡谩?br>
現(xiàn)在有人跟我說起db4o這樣的數(shù)據(jù)庫(kù)，我認(rèn)為db4o不會(huì)取得成功，因?yàn)樗阱e(cuò)誤的方向發(fā)展。

現(xiàn)在關(guān)系數(shù)據(jù)庫(kù)最流行，最流行的應(yīng)用開發(fā)語(yǔ)言包括Java、C#等，都是面向?qū)ο竺钍秸Z(yǔ)言。開發(fā)語(yǔ)言需要訪問關(guān)系數(shù)據(jù)庫(kù)，需要轉(zhuǎn)換，轉(zhuǎn)換的過程比較繁瑣，于是就誕生了O-R Mapping技術(shù)。這是一種妥協(xié)的結(jié)果，面向?qū)ο蠹夹g(shù)在數(shù)據(jù)庫(kù)領(lǐng)域無法取得成功，在面向?qū)ο箝_發(fā)語(yǔ)言中，就需要一種對(duì)象－關(guān)系映射技術(shù)。我相信，這種妥協(xié)產(chǎn)生的技術(shù)，會(huì)越來越流行。

我也認(rèn)為，這是一個(gè)正確的選擇。就如高級(jí)語(yǔ)言不會(huì)嘗試取代匯編，無論高級(jí)語(yǔ)言有多好，最多在其上增加抽象層。例如Java使用bytecode、C#使用IL這樣，使用一種抽象層，而不是嘗試取代匯編。

O-R Mapping技術(shù)除了簡(jiǎn)單映射之外，需要一種OQL，混合SQL和面向?qū)ο筇卣鳎峁┯成浞奖愕耐瑫r(shí)，保留關(guān)系數(shù)據(jù)庫(kù)提供的強(qiáng)大功能。例如聚合、排序等關(guān)系運(yùn)算必須在OQL中提供。由于程序中的返回結(jié)果，有時(shí)不需要映射成對(duì)象，所以O(shè)QL必須提供另外一種功能，數(shù)據(jù)查詢。很多O-R Mappping產(chǎn)品都提供了基于對(duì)象的OQL和基于數(shù)據(jù)的OQL。

這導(dǎo)致包括三個(gè)部分：
1、應(yīng)用程序使用OQL
2、O-R Mapping解釋或者編譯OQL
3、對(duì)象數(shù)據(jù)庫(kù)負(fù)責(zé)數(shù)據(jù)處理

如果O-R Mapping使用解釋的方式處理OQL，則會(huì)包括產(chǎn)生SQL、組裝對(duì)象等操作。效率通常都不會(huì)很好，現(xiàn)在的O-R Mapping產(chǎn)品基本都是基于解釋的方式處理。

如果O-R Mapping使用編譯的方式，可以優(yōu)化產(chǎn)生SQL，動(dòng)態(tài)創(chuàng)建SQL存儲(chǔ)過程，減少SQL交互的過程，能夠獲得很好的性能，可以做到比絕
大多數(shù)人直接使用SQL性能都要好。我曾經(jīng)做過一個(gè)實(shí)驗(yàn)性的實(shí)現(xiàn)，取得很好的效果，可惜由于種種原因，沒有繼續(xù)下去。

我認(rèn)為，下一代的O-R Mapping產(chǎn)品，都將會(huì)采用編譯的方式，因?yàn)樵诤芏嗲樾蜗拢貏e是復(fù)雜對(duì)象的處理方面，可以有大幅度的性能提升，在某些場(chǎng)景下，可以數(shù)倍甚至數(shù)十倍的性能提升。

一直不是很看好Hibernate，因?yàn)槠渲饕髡遟avin對(duì)編譯技術(shù)不了解，2.x版本的HQL語(yǔ)法很搞笑，實(shí)現(xiàn)也是很搞笑的，簡(jiǎn)單的文本替換，看到讓人目瞪口呆。3.0之后加入了HQL的AST（抽象語(yǔ)法樹），但這不是他本人的做的，其他愛好者加入進(jìn)來，3.1還是沒有很好融合進(jìn)來。之后的版本我就沒有繼續(xù)關(guān)注了。

我覺得O-R Mapping完全就是一種編譯技術(shù)，不懂編譯技術(shù)的人去作這件事清總會(huì)有些不妥。這不單是Hibernate的問題，也是其他O-R Mapping產(chǎn)品的問題。


我的觀點(diǎn)：
1、Java、C#、C++等語(yǔ)言在處理關(guān)系數(shù)據(jù)方面沒有優(yōu)勢(shì)。SQL是關(guān)系數(shù)據(jù)處理的領(lǐng)域?qū)Ｓ谜Z(yǔ)言（DSL），更適合處理關(guān)系數(shù)據(jù)，提供強(qiáng)大的功能。
2、關(guān)系數(shù)據(jù)是主流，希望應(yīng)用開發(fā)人員使用O-R Mapping，而不懂關(guān)系數(shù)據(jù)庫(kù)，這是不現(xiàn)實(shí)的。
3、O-R Mapping技術(shù)還有很大發(fā)展空間，以后在功能、性能等方面都會(huì)有重大提升，最終成熟。



文章來源:http://www.cnblogs.com/jobs/archive/2007/04/23/723297.html