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