我的腦海裏緊緊裹着關係數據庫，以及如何有效地對它們進行編碼。我的大部分經驗是使用MySQL和SQL。我喜歡我聽到的關於基於文檔的數據庫的許多事情，尤其是當最近的播客中有人提到巨大的性能優勢時。所以，如果我要走這條路，那麼我必須採取哪些心理步驟才能從SQL轉移到NO-SQL？開發人員必須採取什麼「精神步驟」才能開始從SQL轉移到NO-SQL（CouchDB，FathomDB，MongoDB等）？
如果它在你的答案中有所不同，我主要是C＃開發人員（今天，無論如何）。我習慣於像EF和Linq到ORM的ORM。在ORM之前，我使用泛型和數據收集器來轉換自己的對象。也許這很重要，也許不重要。
這裏有一些更具體：
（隨意添加你自己在這裏的問題）
首先，每個NoSQL商店是不同的。所以它不像在Oracle或Sql Server或MySQL之間選擇。它們之間的差異可能很大。
例如，使用CouchDB（如果你喜歡動態查詢），你不能執行即席查詢。它非常適合在線 - 離線場景，並且足夠小，可在大多數設備上運行。它有一個RESTful接口，所以沒有驅動程序，沒有ADO.NET庫。爲了查詢它，您可以使用MapReduce（現在這在NoSQL空間中非常普遍，但並非普遍存在）來創建視圖，並且這些視圖以多種語言編寫，儘管大多數文檔都是針對Javascript的。 CouchDB也被設計爲崩潰，也就是說如果出現問題，它會重新啓動進程（Erlang進程或一組鏈接進程，而不是整個CouchDB實例）。
的MongoDB的設計是具有高性能，有司機，並似乎少了很多的人在.NET世界，因爲這是一個飛躍。我相信雖然在崩潰的情況下可能會丟失數據（它不提供與CouchDB相同的寫入相同級別的事務保證）。
現在，這兩個都是文件的數據庫，因此他們共享他們的數據是非結構化的。沒有表格，沒有定義的模式 - 它們是無模式的。儘管他們並不像關鍵價值商店，但他們堅持認爲，你所持有的數據對他們來說是可理解的。藉助CouchDB，這意味着使用JSON，而對於MongoDB，這意味着使用BSON。
有MongoDB的和CouchDB的之間有許多其他方面的差異和這些在NoSQL的空間被認爲是在他們的設計非常接近！
除了文檔數據庫，其是面向網絡的解決方案，如Neo4j的，柱狀店（面向列，而不是他們如何堅持數據行導向），等等。
除了MapReduce之外，大多數NoSQL解決方案中常見的東西是它們不是關係數據庫，而且大多數不使用SQL樣式語法。典型的查詢遵循一種命令式的編程模式，而不是SQL的聲明式風格。
另一個通常常見的特徵是，通常由關係數據庫提供的絕對一致性用於最終一致性模型的交易。我對任何希望使用NoSQL解決方案的人的建議是，首先要真正瞭解他們的要求，瞭解SLA（需要什麼級別的延遲;當解決方案需要擴展時，必須保持多長時間的一致性;預計負載;負載是一致的還是會飆升的;用戶對數據的看法如何一致，他們是否應該在查詢時始終看到他們自己的寫入，他們的寫入是否應該立即對所有其他用戶可見;等等。 ..）。瞭解到你無法擁有所有的東西，請閱讀Brewers CAP論壇，它基本上說你不能擁有絕對的一致性，100％的可用性，並且是分區容錯（當節點不能通信時應付）。然後查看各種NoSQL解決方案，並開始消除那些不符合您的要求的設計，瞭解從關係數據庫遷移並非微不足道，並且與其相關的成本（我發現將組織遷移到就會議，討論等方面而言，這一方向本身非常高，防止集中在其他潛在利益領域）。大多數情況下，你不需要ORM（該方程的R部分剛剛失蹤），有時候只是二進制序列化可能是好的（比如DB4O或鍵值存儲），像Newtonsoft JSON/BSON庫可能會有幫助，可能會自動映射器。我發現使用C＃3進行工作與使用像Python這樣的動態語言相比，是一個明確的成本。在C＃4中，這可能會略微改進，例如DLR中的ExpandoObject和Dynamic。
看你的3點特定的問題，所有這取決於你採用的NoSQL解決方案，所以沒有一個答案是可能的，但與告誡，非常籠統：
如果堅持的對象（或更可能的聚合）作爲一個整體，你的連接通常會在代碼中，儘管你可以通過MapReduce來做一些這樣的事情。
同樣，它依賴於Couch，但您可以通過HTTP對特定資源或MapReduce視圖執行GET GET。
很可能沒有什麼。只需注意序列化和反序列化情況。我發現的難點在於如何管理代碼版本。如果該屬性純粹是爲了推送到一個接口（GUI，Web服務），那麼它往往不是一個問題。如果財產是一種行爲依賴的內部狀態，那麼這會變得更加棘手。
希望它有幫助，祝你好運！
只要停止思考的數據庫。
想想你的域名建模。按照良好的模式和實踐構建您的對象來解決手頭的問題，而不必擔心持久性。
只是爲了澄清，從關係思維轉變爲無sql思維方式所需的步驟是完全忽略持久性關注點？ – 2012-08-21 20:09:13
感謝您投入您的時間在這個答案。你已經幫助弄清了幾件事情。由於學習曲線，我一直在密切關注MongoDB。我非常期待進入MapReduce。聽起來很好玩。 – 2010-02-20 21:25:35
很高興幫助，我在Twitter @NeilRobbins，有興趣聽到你如何得到:) – Neil 2010-02-20 21:35:49