扔掉沉沒成本 嘗試關(guān)系數(shù)據(jù)庫替代品OODBMS
譯文【51CTO精選譯文】我對關(guān)系數(shù)據(jù)庫呈現(xiàn)爆炸式增長一直感到很驚訝，至少在過去10年，應(yīng)用程序都是直接與數(shù)據(jù)庫對話的，大部分都是通過參數(shù)來訪問數(shù)據(jù)庫的。高級開發(fā)人員可能會將應(yīng)用程序的SQL語句放在源代碼之外，可能是一個文本文件，也可能是數(shù)據(jù)庫中的一個配置表。后來我們看到了數(shù)據(jù)層的崛起，再往后發(fā)展就變成了使用Web Service對應(yīng)用進(jìn)行松耦合。現(xiàn)在許多開發(fā)人員添加了一個對象——角色建模（ORM）系統(tǒng)或在數(shù)據(jù)庫上進(jìn)行抽象設(shè)計，只是為了產(chǎn)生一個數(shù)據(jù)層。
過去20年，開發(fā)人員一直在嘗試找出關(guān)系數(shù)據(jù)庫要如何改變才能更好地滿足人們的需要。我對關(guān)系數(shù)據(jù)庫管理系統(tǒng)（RDBMS）相關(guān)的歷史有一點了解，一般來說，關(guān)系數(shù)據(jù)庫的速度快，兼容ACID，標(biāo)準(zhǔn)化（大部分是）以及易于理解。開發(fā)人員可以在一個廠商的關(guān)系數(shù)據(jù)庫基礎(chǔ)上開發(fā)應(yīng)用程序，然后不用費太多精力就可以轉(zhuǎn)移到了一個廠商的關(guān)系數(shù)據(jù)庫上。實際上，許多系統(tǒng)要受不同數(shù)據(jù)庫廠商的制約，只不過大部分開發(fā)人員自己還不知道罷了。
另一個需要考慮的事情是關(guān)系數(shù)據(jù)庫的替代品（如面向?qū)ο蟮臄?shù)據(jù)庫管理系統(tǒng)，OODBMS）在過去已經(jīng)有很多討論了，但這個替代品速度緩慢，完全專有化，廠商不多，缺乏ACID兼容，對于大多數(shù)開發(fā)人員而言都還很神秘。這算不上是一個成功的替代方案，嘗試OODBMS的人都是引火燒身，最近主流的OODBMS是Smalltalk。51CTO之前也報導(dǎo)過其他的關(guān)系數(shù)據(jù)庫替代品，如NoSQL，Oracle Coherence和Terracotta等等。
令人沮喪的是關(guān)系數(shù)據(jù)庫卻一直在穩(wěn)步增長，關(guān)系數(shù)據(jù)庫根本不能滿足大多數(shù)應(yīng)用程序中包含的業(yè)務(wù)模型，業(yè)界喜歡稱之為“阻抗不匹配”。
為什么我對關(guān)系數(shù)據(jù)庫沒有好感？
我負(fù)責(zé)的應(yīng)用程序有數(shù)據(jù)存儲需求（我負(fù)責(zé)編程和支持這些企業(yè)應(yīng)用套件），但最近出現(xiàn)了極不正常的數(shù)據(jù)需求。這里有一個很好的例子：對于那些允許用戶創(chuàng)建他們自己的內(nèi)容類型的應(yīng)用程序（不只是他們自己的內(nèi)容），Sharepoint和Team Foundation Server就是這樣的實例，在數(shù)據(jù)庫級架構(gòu)方面已經(jīng)做得很好了，可以滿足它們的需求，但盡管如此，你看到的存儲系統(tǒng)仍然很混亂，這里有成堆的列，但它們的目的不是由數(shù)據(jù)庫結(jié)構(gòu)自身決定的，而是由每一列的內(nèi)容類型決定的，這意味著開發(fā)人員必須尋求其它方式，被迫重建大量的邏輯。
過去幾年開發(fā)工具廠商開始注意到這個問題，它們發(fā)布了一些列的產(chǎn)品和組件提供了一些幫助，但大多數(shù)仍然是在現(xiàn)有關(guān)系數(shù)據(jù)庫基礎(chǔ)架構(gòu)上進(jìn)行構(gòu)建的，這樣做也是為了保護(hù)客戶已有的投資。
此外，出現(xiàn)了一種不合乎邏輯的現(xiàn)象，人們開始追捧“沉沒成本”（也叫做“賠了夫人又折兵”或“把錢扔到水里了”），在這種情況下，開發(fā)人員寧愿向應(yīng)用程序中增加復(fù)雜的層，這樣肯定會顯著增加時間成本，同時也使應(yīng)用程序維護(hù)和調(diào)試變得更加困難了，但這樣可以彌補應(yīng)用程序和數(shù)據(jù)庫之間的“阻抗不匹配”。ADO.NET實體框架Hibernate下的系統(tǒng)都是很好的例子。我曾經(jīng)研究過ADO.NET實體框架，但我決定不去碰它，它太過于復(fù)雜和龐大了，雖然我也看到過有些做得好的系統(tǒng)隱藏了復(fù)雜性，如OutSystem的敏捷平臺。
同時，面向?qū)ο髷?shù)據(jù)庫管理系統(tǒng)已經(jīng)取得了很大的進(jìn)步，在我朋友的建議下，我下載了db4O，雖然我還沒有使用它，但我的朋友說它確實不錯，我還是很相信我這位朋友的話的，我打算最近對db4O做一番研究。許多面向?qū)ο蟮臄?shù)據(jù)庫目前仍然兼容ACID。通過文檔和一些例子可以看出，它們比關(guān)系數(shù)據(jù)庫的工作界面要少得多，也沒有在ORM根據(jù)和類似的系統(tǒng)上花太多的精力。雖然原始數(shù)據(jù)訪問速度比關(guān)系數(shù)據(jù)庫要慢，特別是讀的速度，但當(dāng)你說明了應(yīng)用程序中不同的數(shù)據(jù)訪問層，加上轉(zhuǎn)換數(shù)據(jù)庫數(shù)據(jù)到本地語言對象的成本，面向?qū)ο蟮臄?shù)據(jù)庫速度會更快。
我認(rèn)識的大部分開發(fā)人員在這個問題上困擾了很久，但他們沒有意識到還有另外的選擇，我認(rèn)為現(xiàn)在是時候嘗試新事物了，再也不能讓應(yīng)用程序因受關(guān)系數(shù)據(jù)庫的限制變得復(fù)雜難懂了。（51CTO編輯注：事實上，關(guān)系數(shù)據(jù)庫的終結(jié)隨著云計算的穩(wěn)步到來而越來越近，已成為業(yè)界中所公認(rèn)的一個趨勢。）
原文：It's time to consider alternatives to RDBMS
作者：Justin James
【編輯推薦】
