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