我最后一次評估NoSQL數據庫，我堅持以關系數據庫將它完成。今天，我再次對他進行評估，這一次，我知道我必須要做出至少一個選擇。但是，選擇卻是如此困難。

傳統觀念中 NoSQL數據庫非常適合某些數據類型，如：非關系數據源。同時，NoSQL被吹捧為最適合Web應用程序的優秀平臺。然而他適合大多數數據，特別是web應用程序的數據是相關型。那么，這是否可以給你一個堅持使用RDMS的理由呢？也不一定，即使很困難，我們還是要做出選擇。

評估NoSQL是一個很茅盾的理論，一些人認為，應該將所有文檔數據存儲在一個文檔中，做鏈接代碼就是褻瀆神明。另外一部分人認為，存儲應用文檔，加入代碼，才是合理選擇。與此同時，不同的數據庫，需要在文檔中限制嵌套數據數量。有的人會鼓勵文檔引用。這是NoSQL數據模型的基本部分，也沒有一個明確的共識。

曾經有一篇很熱的帖子"Why you should never use XYZ"，我想，讀到這里，一定會有人搜索這篇文章。當然，這種文章各式各樣，太過于籠統的標題也沒什么幫助。毫無疑問，會有人會搜索這個文章，然后再找到這個文章，進一步深入，找到該文章的方法遠比成功（理解問題）的故事多。很難知道誰提供了一個有效的技術問題，誰又誤讀了這個問題（或者缺少證據證明其觀點）。

有大量選擇，RDBMS的世界，選擇就很容易。你有4或5個目標，大家工作方式差不多，來選擇環境、預算支持的平臺。對于成熟的產品，風險比較小。 NoSQL的世界，有很多數據庫引擎功能選擇。每一個有自己的獨特優勢，也有致命弱點。所以選擇很難， NoSQL項目生命周期短，嘗試新項目或者流行項目也會有風險。上次，我的的項目是在 CouchDB上，而現在似乎停擺了。

做出這個痛苦決定的原因是，這可能是一個案例：你需要做一大堆工作，才能知道，你做出的選擇對與錯。你可以實體化你的數據模型，了解他與系統的工作情況，但是，這只有你正真撞到南墻，才可以找到裂縫（答案）。以我為例，我建的應用程序是關系數據庫，移動文件存儲的主要因素是，需要一個無模式設計來達到我的目標。使用NoSQL 數據庫存儲關系型數據庫并不是我們所常說的，雖然，這種事常常發生。

現在我在用 Couchbase 和 MongoDB，Mongo對我沒多大吸引力，不過鑒于他非常流行，對于引起來說，很有好處。當然，很多都可以以同樣的方式流行。PHP很流行，因為他的易用性，而不是因為他很好。我現在在使用MongoDB和PHP，也在學習Couchbase，如果你有任何NoSQL平臺的使用感想，歡迎交流。

轉載請注明：文章轉載自：慧都控件網 及英文出處：