我已經聽到很多關於MongoDB，CouchDB，SimpleDB等無模式（經常分佈式）數據庫系統的討論......無模式數據庫系統的吸引力是什麼？
雖然我能理解它們可能對某些目的有價值，但在大多數情況下我的應用程序中，我試圖堅持具有特定類型的特定數量的字段的對象，我只是自動思考關係模型。我總是考慮具有唯一整數ID，空/非空字段，SQL數據類型和選擇查詢以查找集合的行。雖然我被這些新系統的分佈式本質和簡單的JSON/RESTful接口所吸引，但我不明白如何鬆散地鍵入鍵/值哈希值可以幫助我進行開發。爲什麼鬆散型，無模式系統對於保持乾淨的數據集是有好處的？我怎樣才能找到所有日期在x和y之間的項目，當他們可能沒有日期？有沒有加入的概念？
我知道很多系統都有自己的差異和優勢，但是我想知道範式的不同。我想這是一個開放式的問題，但也許社區的答案和他們親眼看到這些系統的優點的方式將有助於啓發我和其他人關於什麼時候我想要利用這些（公認的更多臀部）系統而不是傳統的RDBMS。
我就召喚出一個或兩個常見的原因（我敢肯定人們會寫文章的答案）
高度分佈式系統中，任何給定的數據集可以在多個服務器上傳播。當發生這種情況時，數據庫引擎可以保證的關係約束大大減少。 您的參照完整性的一些將需要在應用程序代碼中處理。這樣做時，你很快就會發現幾個難點：
其結果是邏輯封裝少，便攜性低，而且改變成本更高。許多開發人員發現自己在應用程序代碼中編寫更多邏輯，而在數據庫中編寫更少。極端地說，數據庫模式變得無關緊要。
模式管理 - 特別是在停機時間不是選項的系統上 - 很難。減少模式複雜度可以減少這種困難。
對於分佈式系統（BASE,CAP等），ACID不起作用。 SQL語言（以及某種程度上的整個關係模型）針對事務性ACID世界進行了優化。因此，某些SQL語言功能和最佳實踐是無用的，而其他實際上卻是有害的。一些開發人員對於「反對穀物」感到不舒服，並且傾向於完全放棄SQL，而傾向於從根本上爲其需求設計的語言。
成本：大多數RDBMS系統不是免費的。擴展領域的領導者（Oracle，Sybase，SQL Server）都是商業產品。在處理大型（「網絡規模」）系統時，數據庫許可成本可以達到或超過硬件成本！成本是高到足以改變正常編譯/購買因素急劇走向上的OSS產品上構建自定義解決方案（所有顯著NOSQL產品是OSS）
我只玩過MongoDB，但有一件事真的讓我感興趣的是如何嵌套文檔。在MongoDB中，文檔基本上就像一個記錄。這是非常好的，因爲傳統上，在RDBMS中，如果您需要提取「人員」記錄並獲取相關地址，僱主信息等，那麼您經常需要訪問多個表，將它們合併，創建多個數據庫調用。在像MongoDB這樣的NoSQL解決方案中，您可以嵌套關聯的記錄（文檔），而不必混淆外鍵，加入多個數據庫調用。與那一條記錄相關的一切都被拉下來了。
這在處理對象時特別方便。在很多情況下，您只需將對象存儲爲一系列嵌套文檔即可。
另一方面，如果嵌套的對象是共享的，那麼你應該將它們拉到其他表中。關於面向文檔的數據庫的好處在於，您可以選擇：將對象作爲單獨的實體或嵌套記錄。 – Alexey 2012-11-20 12:42:44
通常情況下，吸引力是蛇油 - 大多數人贊成他們沒有關於關係定理的線索，並在專業人士嘔吐的水平上講SQL。不知道什麼是ACID條件，因爲它們很重要等等。
並不是說它們沒有有效的用途......只是說大部分吸引力是人們不知道他們應該知道什麼，並做出愚蠢的結論。再次，不是每個人都是這樣，但大多數開發人員偏愛他們 - 他們不瞭解數據庫系統所負責的是什麼。
tom對nosql的吸引力不在於rdbms的退化 – 2015-09-04 18:38:29
NoSQL數據庫不是無模式的;模式嵌入在數據中。它們被恰當地稱爲半結構化的。但是，在一些KV數據存儲中，架構甚至可能嵌入代碼中。半結構化方法的優勢有兩個方面：列是行的一部分的靈活性（一列可以有5列，另一列有5列，並且列的特徵具有靈活性（例如，可變長度）
無模式的原因有兩個是巨大的：文檔存儲
我使用微博在Ruby on Rails中用於生產應用程序的SQL和No-SQL。我不是數據庫專家，我不得不承認用Google搜索ACID和類似的術語，因爲他們對我不熟悉。
「啊哈！另一個不知道的趨勢追隨者跳上最新的潮流」你可能會說。但實際上，我對我決定在最近2年的應用中使用MongoDB感到非常滿意，這就是爲什麼......
大腦優化直覺的另一面是我對Magento e-商業系統。我不想抨擊它，因爲它在當時爲我提供了很好的服務，但它確實給處理器帶來了難以計算每種產品屬性的情況。其根本原因是產品數據的Entity-Attribute-Value存儲。緩存或被詛咒是解決方案。
對我來說最主要的優勢是在唯一真正重要的地方進行優化 - 您自己的大腦。如此多的技術在內存，處理器和硬件方面的效率都受到了批評，而且擁有非常直觀理解的數據庫帶來了自己的優點。我們發現向代碼添加功能很快，因爲數據庫看起來很像我們正在建模的真實世界。當我要求電子商務客戶向我展示他們的產品列表時，他們自然會傾向於使用Excel（考慮表格商店）。第一列是簡單：
然後它變得更難和筆記，顏色編碼並鏈接到其他表覆蓋（是的..關係）
因此，在Excel表格，使沒有意義的我並沒有太大的意義，誰的產品一天工作的人的一塌糊塗結束和全天候。我們把手放在空中，並決定瀏覽目錄，然後擊中我！如果您可以將數據存儲在目錄中，這不是很好嗎！？只是列出每個產品的記錄集合，只是列出了該產品的屬性。然後，您可以選擇常用屬性進行索引以便日後檢索。當然，這是一家文件商店。
總之，當你有一個稀疏矩陣問題或隨着時間的推移而改變它們屬性的對象時，文檔存儲非常棒。在一個No-SQL世界中生活了兩年，我無法想象一個沒有這些功能的真實世界應用程序，因爲這個世界本身看起來像一個文檔存儲。
MongoDB（至少與Mongoose一樣）是_NOT_無模式的。 – 2017-11-07 17:08:58