在20世紀60年代后期引入的面向對象技術引起了一場革命。到20世紀80年代后，面向對象的技術已經成為了行業的主流，其原因多種多樣：面向對象不僅簡化了界面的開發，而且也提供了一種更加靈活、簡單數據處理方法，這種方法從根本上改變了應用程序的構建方法。不再像關系型數據庫一樣用死板的二維表格來表示數據，對象技術使用類對數據進行描述。一個對象是一個類的實例，就像一顆特定的橡樹是橡樹類的實例一樣。
對象技術使用繼承方案，使得類是按等級設計的?！跋饦洹鳖惸軌驈母悠毡榈念悺皹洹崩^承數據結構和數據行為。
對象技術能夠更好地描述我們所見的世界，面向對象的語言已經被證實在大多數編程領域更加通用。他們使得編程語言更加接近自然語言和多數軟件開發領域的主流思想。面向對象是一個新的典范，它的影響將持久而深遠。
面向對象的特性很快被添加到各種成熟的語言中，并因此成就了一些語言，如C++。新的面向對象的開發環境出現了，包括Visual Basic，Visual C++，PowerBuilder，Delphi，以及Caché。盡管面向對象的技術在高級開發環境下受到了廣泛支持，它還是需要花一定的時間形成正規的課程。而且還需要花更長的時間來構建一個真正的基于對象的世界——我們目前還沒有到達這樣一個階段。
萬維網上對象技術的發展
隨著萬維網（World Wide Web）轉變為交換各種信息的手段，面向對象的編程語言Java成為Web開發者的最愛?；贑++，Java能夠用來創建可以在瀏覽器執行的小程序（Java applets）。
Sun為了促進Java的發展免費提供Java環境。在短短幾年內，成百上萬的Java環境被復制下載，Java滲透到世界的每一個角落。同時Java引發了更多的面向對象語言，如JavaScript，C＃以及Jscript。Internet的發展也培育了一些新的面向對象語言像Perl和PHP?，F在的開發者使用面向對象的技術已經是理所當然的了。
對象的崛起
對象技術影響了軟件開發的各個方面。對象建模已經占領了應用建模的市場，標準UML建模方法獨占鰲頭。
20世紀90年代，面向對象中間件產品的出現為面向對象的應用提供了安全交流服務。當1998年JMS（Java Messaging Serivce）的出現，使得中間件市場向前跨越了一大步。JMS定義了一整套消息傳遞的應用編程接口（APIs），使得經認證的J2EE應用必須引入JMS服務器。這進一步強化了標準化進程，大大降低了中間件的費用，提供了編寫企業范圍基于對象的應用程序平臺。
XML和Web服務
1998年，HTML，專門用于網頁設計的標識語言，經過進一步發展并標準化，創造出了XML（擴展的標識語言）。XML提供了一整套語法，能夠用于創建與存儲在數據庫中定義相似的自定義數據格式，可以。有了XML，程序能夠把定義附加在數據上，能夠交換數據和數據含義。XML能夠使得有特定標準的數據模型（如發票或者購買訂單）的定義能夠在公司內部或者公司之間進行數據交換。XML引發了Web服務的興起——在不需要客戶定制的情況下，程序能夠與其他程序立即交互。現在出現了兩種Web服務環境——J2EE和.NET。像SQL一樣，XML為程序員提供了獲取數據的標準，但XML同時還提供了一種在對象層定義數據的標準語言。XML和對象技術一樣迅速成長。結果，數據對象的新標準和基于XML的新的開發產品出現了。
對象數據庫——缺失的一環
與軟件開發各個環節中對象技術的快速應用形成鮮明對比，對象數據庫直到現在才開始逐漸被人們所接受。對象數據的遲緩行動原因有很多。
早期的對象語言沒有考慮數據存儲。程序在內存數據上工作，數據作為文件存儲，當程序下次運行時數據也作為文件被讀取。這種方法使得應用程序之間不可能共享數據，數據的恢復、管理、擴展幾乎不可能。
目前在市場上已經有大量的面向對象數據庫產品：Versant，Objectivity，ObjectStore，GemStone等等。他們為面向對象的開發環境提供了相應的數據存儲。這些產品滿足了最初的熱情，甚至這些產品被期望能夠打造一個新的數據庫市場——甚至可能成為市場的領袖。
但不幸的是，這些對象數據庫出現時，關系型數據庫供應商已經積聚了巨大的動力，并占領了大量市場份額。在標準的SQL接口下，訪問關系型數據庫的面向對象程序很容易寫。相反，多數早期的對象數據完全不提供SQL接口，不適合任何查詢應用程序。結果，對象數據庫在商業上沒有建立堅實的基礎。他們在應用領域只創建了一個小市場來管理和存儲復雜對象如CAD/CAM，電信業、多媒體、人工智能，模擬金融設備、病人診治跟蹤系統以及科學應用。
數據庫市場從未特別關注過對象數據庫，直到對象定義語言XML出現，這種情況才有所改變，促進了對象數據庫的再次呈現，因為他們管理XML定義的數據是最合適的。使用XML，必然會提高存儲復雜數據的需求，將進一步引發對象數據庫的復蘇。
03年9月份InfoWorld公布了一項開發員調查，其中有一個驚奇的結果，89.2％的被調查者說他們使用關系型數據庫，52％的被調查者說他們使用面向對象或者XML數據庫。當問及有關存儲數據的類型時，40.2％的人說他們存儲持久的對象，58.9％的人說他們存儲XML數據，89％的人說他們存儲關系型數據。Baroudi Bloor相信對象數據庫比我們想象的用的更加廣泛，隨著需求的激增，將進一步擴大市場份額。
InfoWorld的調查還顯示了面向對象的語言是新應用開發的主流選擇。我們相信這些統計數字反映了當今開發員面臨的困境。他們需要與他們一直使用的面向對象語言有更好協調性的數據庫，但他們有需要關系型數據庫所提供的查詢能力。
關系型數據庫——另一半是如何存在的
只要有程序，就會有數據。IT行業最早具有商業價值之一的就是數據管理。自動的數據管理意味著業務能夠擴展、具有競爭力，沒有它就不可能。所以毫無疑問機智的商業技術員很早把目光聚集在數據管理市場。在對象數據庫產生之前的20年，E.F Codd博士提出的關系型理論找到了出路，開發出商業的關系型數據庫產品。在80年中期，在IT領域有一個宗教式的信仰，認為數據的所有理論問題都已經解決，實踐的問題也會隨之解決。然而，很明顯，事實并不是這樣。
關系型數據庫把數據存儲在簡單的兩維表中，這是一種表達大量數據的有效方法，而且程序員也易于理解。關系型數據庫使用SQL建立了一種標準的數據訪問語言。關系型數據庫有一個邏輯和物理形式清楚的結構，這種結構使得應用程序對數據結構是透明的，而且在很多商業應用程序中工作的很好。
然而，關系理論的基礎之一是數據和使用數據的程序能夠而且應該是相互獨立的。這與對象技術的整個理念是不一致的。對象技術鼓勵設計者使用對象而不是表來思考數據。對象和使用對象的方法是不可能彼此分開的。
如果把汽車作為一個復雜的對象來考慮。當你使用汽車時，你使用一輛完整的汽車，作為一個東西——一個對象來使用。與汽車相聯系的有很多動作（也就是面向對象術語中的方法）。你駕駛汽車，進行換檔，發信號，開車燈，等等。如果汽車是一個對象，這些動作就是對象的方法，他們對汽車而言是基礎性的。這些動作獨立于汽車的想法是荒唐的。當你把你的車停在車庫，你把它作為一個東西來存儲。而不是分別在車庫中的某些地方存放方向盤，轉換器，信號器，車燈。數據和它相對應的處理過程也不能而且也不應該被隔離開來。在對象數據庫中他們是不分開的。
事實上，這兩種觀點各有優缺點。有些處理過程確實是獨立于數據的。尤其是訪問大量數據的查詢操作。簡單的查詢就是根據一些標準來選取數據，而不關心數據是什么，也不用關心數據是如何被組織的，只要它能快速的被取出就可以了。查詢是獨立于數據的，但對象方法則不是。
關系型數據庫的局限性
關系型數據庫有比我們想的更多的局限性。存儲和表示一些相當普通的數據結構也是非常困難的。試想一條公交線路——簡單，有序的一組站點。關系型數據庫以無序的方式存放表，只有創建一個特殊的索引，才能提取有序的數據。對象數據庫就沒有這個問題，它有有序的數組，不需要索引——這種索引是因為關系數據結構的局限性而要求創建的人工索引。
另一個簡單的例子是產品用料單——在制造系統中記錄一個產品和它的組件。組件自身也許還有組件，組件的組件還有組件，以此類推。一個關系型數據表不能表達這種部件與部件的部件之間的關系。而這些關系卻是重要的數據。查詢一個產品數據庫，它的所有組件應該是一目了然的。關系型數據庫結構使得開發員花費很多的工作來回答這種簡單的查詢，非常的復雜、困難。與這個例子類似的例子：地圖和它的路、河、路標；網站和它的頁面、鏈接以及圖像。實際上，搜集的信息越復雜，等級層次和交叉層次就越多，在簡單二維表的關系型數據庫就越不可能表達清楚。對象數據庫沒有這樣的限制，事實上，他們就是為了解決這個問題而設計的。
雖然關系型數據庫發展成熟，在這十年中發展也非常迅猛，但我們還聽到一些項目因為所使用的關系數據的性能不是很好而導致失敗。通常，是因為關系型數據庫物理上存儲數據的方法導致的。對開發員而言，為了集合他們所需的數據，他們常常不得不進行這個表與另一個表聯接，再與另外的表聯接，然后再與另一個表聯接。為了提取數據，數據庫運行優化程序來判斷提取數據的最好方法，然后再提取數據。這樣的處理常常要花費很長的時間，結果就大大影響了性能。盡管關系型數據庫優化器已經改善了運行時間，但他們還需要比對象數據庫更多的處理時間。
關系型數據庫和“阻抗不匹配”障礙
關系型數據的一個問題是他們所使用的基本數據結構是一種二維形式的表。在關系理論中，數據應該被組織成規范的表——也就是數據應該按唯一的方式組織，使得程序員能夠消除冗余，確保數據變化的一致性。這種設計技術的引入確保了關系表中的數據是一組獨立的、通過鍵相關的數據。這種技術來自集合論的數學理論，但問題是集合論不能表達數據之間所有的關系和結構。
以規范的方式存儲數據常常要求程序員在存入數據庫之前分解對象，并且重新組織數據，但要使用它是，在使用SQL查詢（多重連接）。就像在車庫中存儲車時，你把它的門、椅子、輪子等等分別卸下來存放。這是非常耗時的，而是也是沒有任何意義的。
但面向對象的語言占主導地位時，問題就越發明顯了。這個問題通常被稱為對象－關系不匹配障礙。這個問題是由于面向對象語言和關系型數據庫使用語言的方法不同導致的，結果這個問題只能有程序員自己來解決。事實上，大多數關系型數據庫在使用的時候并不是完全規范的，但即使是這樣，不匹配問題還是發生，對編程人員的工作造成了很大的困難。我們可以估計使用關系型數據庫的面向對象開發員25％到40％的時間用于編寫代碼來解決對象與關系表的匹配問題。
也許這個根本性困難產生了對對象數據的強烈需求，但多數對象數據庫也有一個很大的問題：他們對SQL的支持很少。而許多軟件工具需要SQL接口，尤其是商業智能應用。甚至有SQL接口的對象數據庫也不能創建用于管理商業智能應用所產生的這類查詢機制。
對象－關系數據庫
關系型數據庫的供應商并沒有忽視對象的出現。顯然，規范復雜數據是沒有意義的。舉個極端的例子，如果你要規范一個位圖形式的圖像——是一系列的象素表示的——你最終要得出一個表，這個表的行是象素，并且主鍵的屬性反映他們的順序。很明顯最好是把這個數據作為一個對象來存儲。
他們提出了“對象－關系”數據庫的創意，這個創意中保留了關系型數據庫的結構，但允許關系表中的列含有一個復雜的對象。這些對象能夠捆綁處理復雜數據的處理過程（一種存儲過程）。并且SQL能夠允許調用與關系型等同的“對象方法”。
這種方法是對數據關系理論的一種嘲弄，事實上，它完全忽略了這個理論，但又允許復雜數據（地圖，矢量圖，圖表，甚至整個表格）被定義為一個項目存放在關系結構中。因此，這些功能被實現并商品化。Informix稱它的嵌入過程為DateBlades，Oracle稱之為Cartridges。
對象－關系數據庫成為存儲數據時對象數據庫的一種替代方案，但根本的問題它并沒有解決。對象－關系數據庫還是受不匹配障礙的困擾。
對象數據庫與關系型數據庫
實踐中，對象數據庫相對于關系數據庫有顯著的優勢。
他們能更快的運行事務處理程序
他們能夠更有效的處理對象
他們能夠提供更好的開發效率
他們能夠管理更容易
在一些例子中，因為是性能方面的原因，用對象數據庫能夠替代關系型數據庫。在不能存儲復雜對象的大規模的業務處理程序中確實是這樣的——也許有些人會認為這個必然是關系型數據庫的領地。
對象數據庫最大的性能優勢是他們不必像關系型數據庫一樣在數據使用之前先連接數據。他們就以使用數據的方式存儲數據，這就大大提高了性能。對象數據庫能夠使用緩存技術，這樣就使得在請求數據時數據就已經存放在內存中了。對象數據庫在抽取數據時幾乎不需要進行優化。
但開發一個新的系統，處理復雜數據如文檔、復雜圖表、網頁、多媒體等的需求不斷增長時，這些需求對象數據庫可以很好的滿足。
當今面向對象的前景
在軟件開發的各個方面使用對象技術的人群都在不停地增長。甚至在最后一個領域——數據庫——盡管對象數據庫還沒有取代關系型數據庫，這種增長也是十分顯著的。InfoWorld報告說52%的開發員在使用對象數據庫或者XML數據庫（通常也是一種對象數據庫）。還有一些選擇混合形式的數據庫，這種數據庫能比較容易地使用對象結構。隨著新應用程序開發過程中Web接口成為一個必不可少地部分，Web服務成為應用系統交互地一種可行的機制，構建一個面向對象的世界似乎是當今的現實。
03年9月的InfoWorld調查也顯示了使用面向對象語言的程序員幾乎無處不在。事實上，盡管有些人宣稱使用C語言，但是面向對象的語言還是成為當今90％的程序員的選擇。調查也顯示了程序員比較喜歡基于Web的應用，易用的對象編程和腳本語言。隨著越來越多的有著正規培訓的軟件工程師進入市場，面向對象技術將成為新應用開發的唯一選擇。
結論
也許關系型數據庫將繼續領導數據庫市場，而對象數據庫在市場上只占有一席之地。也許對象數據庫將進一步提升市場份額，因為他們能夠處理當今使用的復雜的數據。然而，我們認為還有其他的可能：數據庫技術可能發展出一種真正的混合型產品，這種產品能提供關系接口和對象接口雙重優勢。我們知道這是有可能的。事實上，至少有一種產品，來自InterSystems的Caché，就是這樣一個產品。（Caché數據庫，描述他自己時，既不是說是關系型的，也不是說是對象的，而是后關系型數據庫）。數據庫供應商——不管他們的產品是屬于關系型還是對象型——都會朝著這個方向前進的。
這種混合產品的方法包括給數據庫提供一個映射層，程序員通過映射層訪問數據庫。映射層應該基于開發的標準以解決不匹配障礙問題。數據庫的調用能夠用SQL完成，也可以直接請求對象類或者類的集合。映射層能夠把這些調用轉換為對數據庫的物理數據請求以抽取數據。這種方法將消除不匹配的障礙。
改變任何一種數據類型都是非常大的挑戰。對象數據庫需要快速索引能力，以從龐大的數據集中抽取數據。在這方面做得比較好的關系型數據庫使用位圖索引技術，但數據一旦更新，這些索引就需要重新建立。因為這個原因，很少有對象數據有這個功能。對關系數據庫而言，他們需要提供更加靈活的物理數據結構。在發展過程中，關系型數據庫傾向于在物理層使用表。他們需要放棄這種不靈活的限制，允許存儲多種數據結構。數據庫使用者將獲得最大的收益。試想把對象數據庫的優勢和關系型數據庫的優勢整合在一起：
好的處理性能
復雜數據管理
管理簡便
快速開發
靈活的查詢功能
標準的數據訪問接口
更好地適用于商業智能應用
這種混合產品使使用一個數據庫引擎成為可能，并且所有應用只有一個數據定義集。Baroudi Bloor相信企業界需要混合式的數據庫產品。供應商們必須放棄他們對關系數據庫宗教式的傾向，轉向更具優勢的混合式的數據庫，否則的話他們將陷于COBOL以及打孔卡片的深淵而不能自撥。