我的头脑牢牢地围绕着关系数据库，以及如何有效地针对它们进行编码.我的大部分经验是使用MySQL和SQL.我喜欢我听到的关于基于文档的数据库的许多事情，尤其是当有人在最近的播客中提到巨大的性能优势时.那么，如果我要沿着这条路走下go ，我必须采取哪些心理措施来从SQL转变为非SQL？
如果这对你的答案有任何影响，我主要是一名C#开发者(无论如何，今天).我习惯了像EF和Linq到SQL这样的ORM.在使用ORMs之前，我使用泛型和数据读取器滚动自己的对象.也许这很重要，也许不重要.
以下是一些更具体的例子:
(请在此处随意添加您自己的问题)
首先，每个NoSQLstore 都是不同的.所以这不像是在Oracle、Sql Server或MySQL之间做出 Select .它们之间的差异可能很大.
例如，使用CouchDB，您无法执行特别查询(如果愿意，可以执行动态查询).它非常擅长在线-离线场景，并且足够小，可以在大多数设备上运行.它有一个RESTful接口，所以没有驱动程序，没有ADO.NET图书馆.要查询它，可以使用MapReduce(现在这在NoSQL空间中非常常见，但并不普遍)来创建视图，这些视图是用多种语言编写的，尽管大多数文档都是针对Javascript的.CouchDB也被设计为崩溃，也就是说，如果出现问题，它只会重新启动进程(Erlang进程或一组链接进程，通常不是整个CouchDB实例).
MongoDB被设计成高性能的，有司机的，对世界上的很多人来说似乎不是什么飞跃.网络世界正因为如此.但我相信，在崩溃情况下，数据可能会丢失(它不能提供与CouchDB相同级别的写入事务保证).
现在这两个数据库都是文档数据库，因此它们的数据都是非 struct 化的.没有表，没有定义的模式——它们是无模式的.不过，它们不像键值存储，因为它们坚持认为您保存的数据对它们来说是可理解的.对于CouchDB，这意味着使用JSON；对于MongoDB，这意味着使用BSON.
MongoDB和CouchDB之间还有许多其他差异，NoSQL空间认为它们的设计非常接近！
除了文档数据库，它们是面向网络的解决方案，如Neo4J、列存储(在如何持久化数据方面是面向列的，而不是面向行的)，以及许多其他解决方案.
除了MapReduce之外，大多数NoSQL解决方案都有一个共同点，那就是它们不是关系数据库，大多数都不使用SQL风格的语法.典型的查询遵循命令式编程模式，而不是SQL的声明式风格.
另一个典型的共同特征是，绝对一致性(通常由关系数据库提供)被用来交换最终的一致性模型.
我给任何想要使用NoSQL解决方案的人的建议是，首先要真正了解他们的需求，理解SLA(需要多大程度的延迟；随着解决方案的扩展，该延迟必须保持多大程度的一致性；预期的负载规模是多大；负载是一致的还是会激增；用户对数据的查看需要多大程度的一致性，他们在查询时是否总是看到自己的写入，他们的写入是否会立即被我们所有其他人看到ER；等等……).了解你不能拥有一切，阅读Brewers CAP theorum，它基本上说你不能拥有绝对的一致性、100%的可用性和分区容限(在 node 无法通信时应对).然后研究各种NoSQL解决方案，并开始消除那些不符合您需求的解决方案，要明白，从关系数据库转移并非微不足道，而且会带来相关的成本(我发现，从会议、讨论等方面来看，将一个组织转移到这个方向的成本非常高，这会妨碍人们关注其他潜在利益领域).大多数情况下，您不需要ORM(方程式的R部分刚刚丢失)，有时只需要二进制序列化就可以了(例如，使用DB4O或键值存储)，像Newtonsoft JSON/BSON库这样的东西可能会有所帮助，automapper也可能会有帮助.我确实发现，与使用动态语言(比如Python)相比，使用C#3 theere无疑是一项成本.有了C#4，使用ExpandoObject和DLR的动态功能，这可能会有所改善.
看看你的3个具体问题，这完全取决于你所采用的NoSQL解决方案，因此不可能只给出一个答案，但是有一点需要注意，概括来说:
如果将对象作为一个整体进行持久化(或者更可能是聚合)，那么连接通常会在代码中进行，不过可以通过MapReduce进行部分操作.
同样，这要视情况而定，但使用coach，您可以针对特定资源或MapReduce视图执行GET-over HTTP.
很可能什么都没有.只需留意序列化、反序列化场景.我发现的困难在于如何管理代码的版本.如果该属性纯粹是为了推送到一个界面(GUI、web服务)，那么它的问题就不那么严重了.如果属性是行为所依赖的一种内部状态，那么这可能会变得更加棘手.
希望有帮助，祝你好运！