原創(chuàng)|行業(yè)資訊|編輯:龔雪|2015-01-05 09:49:33.000|閱讀 417 次
概述:這是我再一次評估NoSQL數(shù)據(jù)庫,我知道選擇很困難,但是我還是必須要做出選擇。
# 界面/圖表報表/文檔/IDE等千款熱門軟控件火熱銷售中 >>
我最后一次評估NoSQL數(shù)據(jù)庫,我堅持以關(guān)系數(shù)據(jù)庫將它完成。今天,我再次對他進行評估,這一次,我知道我必須要做出至少一個選擇。但是,選擇卻是如此困難。
傳統(tǒng)觀念中 NoSQL數(shù)據(jù)庫非常適合某些數(shù)據(jù)類型,如:非關(guān)系數(shù)據(jù)源。同時,NoSQL被吹捧為最適合Web應(yīng)用程序的優(yōu)秀平臺。然而他適合大多數(shù)數(shù)據(jù),特別是web應(yīng)用程序的數(shù)據(jù)是相關(guān)型。那么,這是否可以給你一個堅持使用RDMS的理由呢?也不一定,即使很困難,我們還是要做出選擇。
評估NoSQL是一個很茅盾的理論,一些人認為,應(yīng)該將所有文檔數(shù)據(jù)存儲在一個文檔中,做鏈接代碼就是褻瀆神明。另外一部分人認為,存儲應(yīng)用文檔,加入代碼,才是合理選擇。與此同時,不同的數(shù)據(jù)庫,需要在文檔中限制嵌套數(shù)據(jù)數(shù)量。有的人會鼓勵文檔引用。這是NoSQL數(shù)據(jù)模型的基本部分,也沒有一個明確的共識。
曾經(jīng)有一篇很熱的帖子"Why you should never use XYZ",我想,讀到這里,一定會有人搜索這篇文章。當然,這種文章各式各樣,太過于籠統(tǒng)的標題也沒什么幫助。毫無疑問,會有人會搜索這個文章,然后再找到這個文章,進一步深入,找到該文章的方法遠比成功(理解問題)的故事多。很難知道誰提供了一個有效的技術(shù)問題,誰又誤讀了這個問題(或者缺少證據(jù)證明其觀點)。
有大量選擇,RDBMS的世界,選擇就很容易。你有4或5個目標,大家工作方式差不多,來選擇環(huán)境、預(yù)算支持的平臺。對于成熟的產(chǎn)品,風險比較小。 NoSQL的世界,有很多數(shù)據(jù)庫引擎功能選擇。每一個有自己的獨特優(yōu)勢,也有致命弱點。所以選擇很難, NoSQL項目生命周期短,嘗試新項目或者流行項目也會有風險。上次,我的的項目是在 CouchDB上,而現(xiàn)在似乎停擺了。
做出這個痛苦決定的原因是,這可能是一個案例:你需要做一大堆工作,才能知道,你做出的選擇對與錯。你可以實體化你的數(shù)據(jù)模型,了解他與系統(tǒng)的工作情況,但是,這只有你正真撞到南墻,才可以找到裂縫(答案)。以我為例,我建的應(yīng)用程序是關(guān)系數(shù)據(jù)庫,移動文件存儲的主要因素是,需要一個無模式設(shè)計來達到我的目標。使用NoSQL 數(shù)據(jù)庫存儲關(guān)系型數(shù)據(jù)庫并不是我們所常說的,雖然,這種事常常發(fā)生。
現(xiàn)在我在用 Couchbase 和 MongoDB,Mongo對我沒多大吸引力,不過鑒于他非常流行,對于引起來說,很有好處。當然,很多都可以以同樣的方式流行。PHP很流行,因為他的易用性,而不是因為他很好。我現(xiàn)在在使用MongoDB和PHP,也在學習Couchbase,如果你有任何NoSQL平臺的使用感想,歡迎交流。
轉(zhuǎn)載請注明:文章轉(zhuǎn)載自:慧都控件網(wǎng) 及英文出處:
本站文章除注明轉(zhuǎn)載外,均為本站原創(chuàng)或翻譯。歡迎任何形式的轉(zhuǎn)載,但請務(wù)必注明出處、不得修改原文相關(guān)鏈接,如果存在內(nèi)容上的異議請郵件反饋至chenjj@fc6vip.cn
文章轉(zhuǎn)載自:慧都控件網(wǎng)