将网上商店存储移动到NoSQL解决方案

如果你有一个基于SQL Server关系数据库的网上商店解决方案,那么迁移到NoSQL存储的原因是什么？将依赖关系的数据存储迁移到NoSQL甚至是否有意义？如果从头开始,你会选择NoSQL解决方案而不是关系网络项目,这会在一段时间之后再次出现一堆表格,如文章,分类,税率,价目表等,以及它们之间的关系. ？

.NET(4.0)对MongoDB或MongoDB对.NET 4.0的支持有什么支持？对于MongoDB,我可以依靠类似于EF向导,L2SQL向导等的丰富代码生成工具吗？

因为就我到目前为止所读到的,NoSQL主要适用于文档存储,更简单的对象模型.

您对此问题的回答将帮助我做出正确的基础架构设计决策.

更新:如果我正在围绕ASP.NET MVC开发我的解决方案并且严重依赖于Model类,那么选择DB4o来简单地将对象序列化和反序列化到数据存储区和从数据存储区反序列化是否是最简单的方法？

这是一个非常开放的问题.

迁移到现有软件的NoSQL数据存储区

通常,现有的关系技术有很多经验和知识.当你的应用程序运行良好时,它可能不值得努力.但是,如果当前解决方案存在无法解决的问题,那么它是一个选项.

将依赖关系的数据存储迁移到NoSQL甚至是否有意义？

那么你必须考虑到三种技术(Document-DB,RDBMS,Object Database)彼此非常不同.

在关系世界中,您将数据标准化并在运行时将它们连接在一起.只要数据大小不大,这种方法就可以正常工作.这里经常出现问题:当你有大量标准化数据时,你需要做很多连接,这会花费很多性能.当然,对象和表之间的映射可能非常棘手.

在对象数据库中,每个对象被单独存储,并且"关系"以指针的形式存储.因此,当对象A具有对对象B的引用时,对象数据库存储此引用.因此,要检索"关系",不需要连接操作.因此,"关系"很便宜.总之,对象数据库非常善于处理关系.

在像MongoDB这样的文档数据库中,完整的对象图存储为文档.文档数据库与文档级一起使用.所以这里没有真正的"关系".您通常只是存储/加载文档.因此,当您可以为场景建模以便大多数操作仅在单个文档上工作时,它非常高效且简单.

这是一篇很好的博客文章,它比较了MongoDB(文档数据库)和db4o(对象数据库)的设计差异

最后,您的模型应该适合您的数据库.例如,不要尝试将模型用于关系数据库,并将其以1:1的形式存储在文档数据库中.另见Ayende的博客,关于对象数据库的建模.

.NET(4.0)对MongoDB或MongoDB对.NET 4.0的支持有什么支持？

盖茨副总裁已经为MongoDB做了回答..NET 4.0版本的db4o正在开发中.同时3.5版本也适用于4.0框架.

对于MongoDB,我可以依靠类似于EF向导,L2SQL向导等的丰富代码生成工具吗？

对于MongoDB和db4o,您不需要生成代码.您的类是架构.您只需存储对象,数据库将处理剩下的事情.另见盖茨VP答案

因为就我到目前为止所读到的,NoSQL主要适用于文档存储,更简单的对象模型.

那么范围很大.从非常简单的键值存储,到更高级的文档数据库,面向colum的数据库,图形数据库和对象数据库.

当然,当您拥有类似文档的数据(例如博客软件)时,文档数据库的工作非常出色.而图形和对象数据库擅长处理极端复杂的数据结构.