将网上商店存储迁移到 NoSQL 解决方案
如果您有一个基于 SQL Server 关系数据库的网上商店解决方案，那么迁移到 NoSQL 存储的原因是什么（如果有）？将严重依赖关系的数据存储迁移到 NoSQL 是否有意义？如果从头开始，对于网店项目，您会选择 NoSQL 解决方案而不是关系型解决方案吗？过了一段时间，该项目将再次以一堆表（例如文章、分类、税率、价格表等）以及它们之间的大量关系结束？
.NET (4.0) 对 MongoDB 的支持如何，或者 MongoDB 对 .NET 4.0 的支持如何？我可以依靠类似于 EF 向导、L2SQL 向导等丰富的 MongoDB 代码生成工具吗？
因为正如我到目前为止所读到的，NoSQL 最适合文档存储、更简单的对象模型。
您对这个问题的回答将帮助我做出正确的基础设施设计决策。
更新：如果我正在围绕 ASP.NET MVC 开发解决方案并严重依赖 Model 类，那么选择 DB4o 来简单地在数据存储中序列化和反序列化我的对象是否是最简单的方法？
If you had a webshop solution based on SQL Server relational DB what would be the reasons, if any, to move to NoSQL storage ? Does it even make sense to migrate datastores that rely on relations heavily to NoSQL? If starting from scratch, would you choose NoSQL solution over relational one for a webshop project, which will, after a while, again end up with a bunch of tables like Articles, Classifications, TaxRates, Pricelists etc. and a magnitude of relations between them?
What's the support like in .NET (4.0) for MongoDB or MongoDB's support for .NET 4.0? Can I count on rich code generation tools similar to EF wizard, L2SQL wizard etc. for MongoDB?
Because as what I have read so far, NoSQL's are mostly suited for document storage, simpler object models.
Your answer to this question will help me make the right infrastructure design decisions.
UPDATE: If I was developing my solution around ASP.NET MVC and rely heavily on Model classes, would it be the easiest way to go to choose DB4o to simply serialize and deserialize my objects to and from datastore?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
嗯，这是一个开放式的问题。
通常，现有关系技术需要大量经验和知识。当您的应用程序运行良好时，它可能不值得付出努力。但是，当您当前的解决方案遇到无法解决的问题时，这是一个选择。
你必须考虑到这三种技术（文档数据库、关系型数据库、对象数据库）彼此之间有很大不同。
这是一个很好的 博客文章比较了 MongoDB（文档数据库）和 db4o（对象数据库）的设计差异
最终您的模型应该适合您的数据库。例如，不要尝试使用关系数据库的模型并将其 1:1 存储在文档数据库中。另请参阅 Ayende 关于对象数据库建模的博客。
盖茨副总裁已经针对 MongoDB 回答了这个问题。 db4o 的 .NET 4.0 版本正在开发中。同时3.5版本在4.0框架上也运行良好。
对于 MongoDB 和 db4o，您都不需要生成代码。您的课程就是架构。您只需存储对象，数据库就会处理其余的事情。另请参阅盖茨副总裁的回答
嗯，范围相当大。从真正简单的键值存储，到更高级的文档数据库、面向列的数据库、图形数据库和对象数据库。
当然，当您存储类似文档的数据（例如博客软件）时，文档数据库可以很好地工作。而图形数据库和对象数据库擅长处理极其复杂的数据结构。
Well quite a open-ended question.
Well often there's a lot of experience and knowledge for the existing relational technologies. When you're application runs fine, its probably not worth the effort. However when you have unsolvable issues with the current solution, then it's an option.
Well you have to consider that the three technologies (Document-DB, RDBMS, Object Database) are very different from each other.
Here's a good blog-post which compares the design-difference of MongoDB (document database) and db4o (object-database)
In the end you model should fit to your database. For example, don't try to use a model for a relation database and store it 1:1 in a document database. See also Ayende's blog about modeling for a object-database.
Gates VP has already answered this for MongoDB. The .NET 4.0-version of db4o is in development. Meanwhile the 3.5 version also works fine on the 4.0 framework.
For both, MongoDB and db4o you don't need to generate code. Your classes are the schema. You just store you objects and the database takes care of the rest. See also Gates VP answer
Well the range is quite big. From really simple key-value-stores, to more advanced document-databases, colum-oriented-databases, graph-databases and object-databases.
Of course the document-database work excellent when you have store document-like data (for example a blog-software). While graph- and object-databases are good at handling extreme complex data structures.
好吧，问题很多，让我们看看我能真正解决哪些问题。
除非你有一个非常大的性能问题。事情是这样的，“网络规模”的性能问题通常是通过非规范化来解决的。 MongoDB 本质上是一个非规范化的数据库。
是的。 MongoDB 非常适合典型的基于 Web 的项目。然而，如果您有丰富的 SQL 经验，您可能会发现报告有点尴尬。
Mongo 有一个可用于 .NET 的驱动程序。
Mongo 没有 L2SQL 或 EF 向导，但实际上不应该有。老实说，您可能最怀念的是用于分析数据库的 Enterprise Manager。
MongoDB 并不真正需要 EF 向导。 EF 是 MS 针对 DB 和对象之间“阻抗不匹配”的解决方案。 MongoDB 没有“阻抗不匹配”，只需将对象填充到数据库中即可。 L2SQL 的情况大致相同。人们已经建立了一些 Linq 支持（只需快速谷歌），但是诸如连接之类的东西将无法工作，因为 Mongo 不执行连接。
从“数据对象”的角度来看，Mongo只需要一个非常轻量级的框架。老实说，这就像将属性填充到数据库中一样简单。如果您想“添加列”，只需将属性添加到对象中，它就会开始保存在数据库中。因此，像 L2SQL 这样的东西开始变得非常不必要。
不要误会我的意思，有不同的查询范例的空间，但在这方面你处于新的领域。 （您将适用于所有键值和面向文档的商店）。
OK, that's a lot of questions, let's see which ones I can really address.
Not unless you have a really big performance problem. Here's the deal, "web-scale" performance problems are typically solved by denormalization. MongoDB is an inherently denormalized database.
Yes. MongoDB is a very natural fit for typical web-based projects. However, if you have lots of SQL experience, you'll probably find the reporting a little awkward.
Mongo has a driver available for .NET.
There's no L2SQL or EF wizard for Mongo, but there really shouldn't be. Honestly, what you'll probably miss most is Enterprise Manager for analyzing the DB.
MongoDB doesn't really need an EF wizard. EF is MS's solution for the "impedance mismatch" between DBs and objects. MongoDB doesn't have the "impedance mismatch", just stuff the objects in the DB and go. Much of the same goes for L2SQL. People have built some Linq support (just a quick google), but things like joins won't work b/c Mongo doesn't do joins.
From a "data objects" standpoint, Mongo only needs a very lightweight framework. Honestly it's as simple as stuffing the properties into the DB. If you want to "add a column", you simply add the property to your object and it starts saving in the DB. So things like L2SQL start becoming really unecessary.
Don't get me wrong, there's room for a different querying paradigm, but in that regards you're in new territory. (you will be for all key-value and document-oriented stores).