對象資料庫 VS 關聯式資料庫

來源:互聯網
上載者:User
對象|資料|資料庫 對象資料庫 VS 關聯式資料庫
我們將對象資料庫管理系統(ODBMS)定義為一個整合了資料庫能力與物件導向程式設計語言能力的資料庫管理系統(DBMS),ODBMS使資料庫物件看起來像是已有的一個或多個程式設計語言中的程式設計語言以象。——Rick Cattell,OMG-93委員會主席。

ODBMS在多使用者客戶機/伺服器環境中提供了持久性儲存空間。ODBMS可以處理對象的並行訪問,提供鎖定和事務保護,保護Object Storage Service器免遭各種類型的威脅,照管像備份和恢複之類傳統任務。ODBMS這所以與關聯式資料庫不同,是因為ODBMS儲存的是對象,而不是表格。對象的引用通過持久性標識(PID)進行,PID可以獨一無二地識別各個對象,可以用來在對象之間建立標記和容器關係。ODBMS還加強了封裝,支援繼承。ODBMS結合了對象屬性和傳統的DBMS功能,如鎖定、保護、交易處理、查詢、版式本、並發和持久性。

ODBMS不是利用分離的語言(如SQL)定義、檢索和處理資料,而是利用類定義和傳統的物件導向的程式語言(通常是C++、SmallTalk和Java語言)構造來定義和訪問資料。ODBMS只來過是儲存空間內語言資料結構的多使用者、持久性擴充。換句話說,客戶就是C++或是Java程式,伺服器就是ODBMS­——沒有像SQL和RPC這樣的可視中間對象。ODBMS將資料庫能力直接整合進語言。

ODBMS的價值。很顯然,最好是以自然的形式儲存那些對象,而不是將資料修飾得光光滑滑或撕得七零八落之後放進關係表格中。

對於那些資料複雜難以在表格裡簡單排列的使用者來說,ODBMS特別適合。ODBMS曾經長期是學者和OO研究人員極為感興趣的領域。最早的商品化ODBMS出現在1986年,是Servio公司(現在的GemStone公司)和Ontos公司推出的。後來(九十年代)Object Design(ODI)、Versant、Objectivity、O2 Technology、Poet、Ibex、UniSQL和ADB MATISSE等公司也加入了這個開拓行列。這些ODBMS廠商首先瞄準了那些複雜資料結構和長命期交易處理的應用程式——包括電腦輔助設計、CASE和智能辦公室等。隨著多媒體、群件、公布式對象和全球資訊網技術的出現,ODBMS與那些深奧難懂的特性現在變成了客戶機/伺服器系統的主流要求。ODBMS技術填補關聯式資料庫最弱的那些空隙——複雜資料、版式本和長生命期事務、持久性Object Storage Service、繼承和使用者定義的資料類型等等。

以下是ODBMS廠商開拓的各個特性:

n        自由建立新的資訊類型

n        快速存取

n        組合結構的靈活視圖

n        與物件導向的程式語言緊密整合

n        利用多繼承支援可定製的資訊結構

n        支援版本事務、嵌套事務和長生命期事務

n        分布式對象儲庫

n        支援綜合物件的生命期管理

對象狂已經掌握了整個行業。物件導向支援人員者正在宣告,對象關聯式資料庫和ODBMS將成為醫治關係技術的所謂弱點的良藥。這純屬胡說……在資料庫上直接地和不加區分地就應用物件導向技術,將再次引入關聯式資料庫花了二十年才克服的那些問題。

在使用者中間,很少有人會懷疑ODBMS最終將成為RDBMS的後繼技術。在詩人William Blake的比喻中,年輕的革命上帝Orc已經開始衰老,變成冷冰冰的暴君Urizen——戒律和標準的守護人。

我們可以兩者兼得。要點是將這兩項技術結合起來,而不是相互扔泥塊。對二十多處踏踏實實的關聯式資料庫研究的開發熟視無睹,不加以利用,就不太應該了。

Date和Pascal都承認目前的SQL資料庫實現有缺點;但他們兩人都有覺得關聯式模式本身能夠處理ODBMS將解決的那些問題,ODBMS有能力,可以利用嵌套關係、域(或使用者定義的資料封裝類型)以及一種比SQL更強大的面向集合語言在關係技術世界裡近似。這些特性完成這項工作,無需追逐對象指標或操縱低級的專用語言記錄結構。沒有必要減輕關係理論的聯合能力。開發人員沒有必要退回到用手工方法去最佳化或重新最佳化應用程式的效能——將時鐘倒拔回去了。Date認為域和對象是同一回事,解決辦法是由關係技術廠商擴充其系統,以包括“適當的域支援”。

StoneBraker注意到純粹的ODBMS還缺乏複雜搜尋、查詢最佳化工具和伺服器可擴充性等領域的功能。而且,許多ODBMS在使用者編程的同一個地址空間裡運行其產品。這意味著在客戶應用程式和ODBMS之間沒有任何屏蔽。此外,與關係DBMS相比,ODBMS的市場突破還極小。最後,對象/關係和SQL資料類型擴充器正在RDBMS語言政治協商環境內滿足某些對象要求。

支援ODBMS的人們覺得,除了僅僅擴充關聯式模式之外,還有更多的方法。事實上,他們已經拒絕了SQL3,理由是不足(正在達成休戰協定)。ODBMS頑固分子認為他們正在為一個新創世界創造更好的管道系統,在這個世界裡資訊系統完全建產在對象基礎之上。在一個由ORB、物件服務、物件導向的程式設計語言和Object Web組成的管道裡,關聯式資料庫成了阻礙。所需要的正是一個純粹的ODBMS。為什麼要堅持用BLOB、預存程序和使用者定義型別來擴充一個像SQL這樣的舊基礎呢?他們寧願自始至終堅持用對象技術,有時從SQL借來某些東西(比如查詢)。他們還在建立一個多使用者、堅實的基礎、包括鎖定、事物處理、恢複和各種工具。
當然我們這裡談論的是David和Goliath。SQL資料庫是目前的山中之王,它們擁有巨額的開發經費,在從MIS商店到客戶機/伺服器低端市場裡有著極好的市場接受度。是不是因為ODBMS能與更好地處理對象,這個山中之王就會被黜?這還有待進一步地觀察。不過,正如Esther Dyson表達的,“利用Table Store對象,就象是將汽車開回家,然後拆成零碎件放進車庫裡,早晨可以再把汽車裝配起來。但是人們不禁要問:這是不是泊車的最有效方法呢”

相關文章

Beyond APAC's No.1 Cloud

19.6% IaaS Market Share in Asia Pacific - Gartner IT Service report, 2018

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。