如果您有基于SQL Server关系数据库的网上商店解决方案，那么迁移到NoSQL存储的原因是什么？将依赖关系的数据存储迁移到NoSQL甚至是否有意义？如果从头开始，你会选择NoSQL解决方案而不是关系网络项目，这会在一段时间之后再次出现一堆表格，如文章，分类，税率，价目表等，以及它们之间的关系。 ？
.NET（4.0）对MongoDB或MongoDB对.NET 4.0的支持有什么支持？对于MongoDB，我可以依靠类似于EF向导，L2SQL向导等的丰富代码生成工具吗？
因为正如我迄今所读到的那样，NoSQL主要适用于文档存储，更简单的对象模型。
您对这个问题的回答将帮助我做出正确的基础设施设计决策。
更新：如果我正在围绕ASP.NET MVC开发我的解决方案并且严重依赖于Model类，那么选择DB4o来简单地将对象序列化和反序列化到数据存储区和从数据存储区中解析是不是最简单的方法？
答案 0 :(得分：8)
这是一个非常开放的问题。
迁移到现有软件的NoSQL数据存储区
对于现有的关系技术，经常有很多经验和知识。当你的应用程序运行良好时，它可能不值得努力。但是，如果当前解决方案存在无法解决的问题，那么它就是一个选项。
将依赖关系的数据存储迁移到NoSQL甚至是否有意义？
那么你必须考虑到这三种技术（Document-DB，RDBMS，Object Database）彼此之间存在很大差异。
这是一个很好的blog-post，可以比较MongoDB（文档数据库）和db4o（对象数据库）的设计差异
最后，您的模型应该适合您的数据库。例如，不要尝试将模型用于关系数据库，并将其以1：1的形式存储在文档数据库中。另请参阅Ayende's blog about modeling for a object-database。
.NET（4.0）对MongoDB或MongoDB对.NET 4.0的支持有什么支持？
Gates VP has already answered this for MongoDB。 .NET 4.0版本的db4o正在开发中。同时3.5版本也适用于4.0框架。
我可以依靠类似于EF向导，L2SQL向导等的MongoDB丰富的代码生成工具吗？
对于MongoDB和db4o，您不需要生成代码。您的类是架构。您只需存储对象，数据库将处理剩下的事情。另请参阅Gates VP answer
因为正如我迄今所读到的那样，NoSQL主要适用于文档存储，更简单的对象模型。
嗯，范围很大。从非常简单的键值存储到更高级的文档数据库，面向字体的数据库，图形数据库和对象数据库。
当然，当您拥有类似文档的数据（例如博客软件）时，文档数据库的工作非常出色。而图形和对象数据库擅长处理极端复杂的数据结构。
答案 1 :(得分：3)
好的，这是很多问题，让我们看看我能真正解决哪些问题。
迁移现有的关系数据存储是否有意义？
除非你有一个非常大的性能问题。这是交易，“网络规模”的性能问题通常通过非规范化来解决。 MongoDB是一个固有的非规范化数据库。
如果从头开始，你会为网店项目选择NoSQL解决方案而非关系型解决方案......
是。 MongoDB非常适合典型的基于Web的项目。但是，如果您有很多SQL经验，那么您可能会发现报告有点尴尬。
.NET 4.0支持？对于MongoDB，我可以依靠类似于EF向导，L2SQL向导等的丰富代码生成工具吗？
Mongo有一个可用于.NET的驱动程序。
Mongo没有L2SQL或EF向导，但确实不应该。老实说，你可能最想念的是用于分析数据库的企业管理器。
MongoDB实际上并不需要EF向导。 EF是MS针对DB和对象之间“阻抗不匹配”的解决方案。 MongoDB没有“阻抗不匹配”，只是填充数据库中的对象然后去。 L2SQL的情况大致相同。人们已经建立了一些Linq支持（只是一个快速的谷歌），但像连接这样的东西将无法工作b / c Mongo不会加入。
从“数据对象”的角度来看，Mongo只需要一个非常轻量级的框架。老实说，这就像将属性填充到数据库中一样简单。如果要“添加列”，只需将属性添加到对象中，它就会开始保存在数据库中。所以像L2SQL这样的东西开始变得非常不必要。
不要误会我的意思，有不同的查询范式，但在这方面，你处于新的领域。 （您将用于所有键值和面向文档的商店。）