Web模式-文档数据库

Question

我想评估一个文档数据库，可能是ASP.Net MVC网站中的mongo。

--一开始的小推理：

大约有200万种产品。

对于rdbms来说，产品模型会非常糟糕，因为会有许多不同类型的产品具有独特的属性。

例如，有isbn，作者，标题，网页等书籍，以及dvds播放时间，导演，艺术家等，以及相当多的类型。

最后，我将有大约9种不同的产品，合并列计数(仅计算一次常见列)约为70到100，而每个单独的产品最多只有15列。

RDBMS中常用的三种方法是：

EAV模型会有非常糟糕的性能特性，如果我想在不同的产品列表中显示一本书的作者(想想起始页面，推荐的产品等等)，这将使它要么不切实际，要么表现得更糟。

忽略列计数，并将其全部放在产品表中:尽管我处理的数据库比较大(按行排列)，但在性能方面，我对20列以上的表没有任何经验，但我想100列可能会有一些影响。

为每种产品类型创建一个表:我个人不喜欢这种方法，因为它会使其他一切复杂化。

C#驱动程序/类：

我想使用NoRM驱动程序，到目前为止，我想我将尝试创建一个包含所有属性的产品dto (分组在细节类中，比如图书详细信息，除了那些应该显示在列表视图中的属性)。

在这个应用程序中，我将使用BookBehavior / DvdBehaviour，它是产品dto的包装器，但只公开了狂欢属性。

现在我的问题：

1. 是我对多列方法的性能关注吗？
2. ，我是否忽略了什么，并且有更好的方法在关系数据库中实现？
3. 在Windows上是否足够稳定？
4. 使用不同的行为包装器是否有意义？

G 215

Answer 1

，我对多列方法的性能关注是否有效？

老实说，我不认为性能是真正的关键问题。如果您有包含100列的2M行，而且这些列永远不会更改，那么Server / MySQL /等实际上会做得很好。它可能会占用大量不必要的空间，但DB可能会有足够的性能。

DB不会做的是非常容易地接受任何更改，我认为这是最主要的问题。试图将列添加到包含200万行的中央表中基本上是一场噩梦。您可以“将”单独的字段“输出”到单独的子表中，但这并不一定解决问题，只是延迟了问题。EAV也是一场噩梦，因为你现在拿出你的200万行，把它们转换成2000万行。

，我是不是忽略了什么，在关系数据库管理系统中有一种更好的方法吗？

只要您愿意做出通常的关系数据库管理系统的牺牲，那么您可能会发现MongoDB对于基本CRUD来说更快、更容易、更灵活。

上的MongoDb是否足够稳定？

我不能跟你说话。论坛上肯定有人在Windows上运行。但对于大多数使用它的人来说，200万张唱片实在是小菜一碟。

，我使用不同行为包装器的方法是否有意义？

你是在建议以下几点？

collection.

• Each产品中的所有产品数据都被标记为一个类型，因此当被代码访问时，会加载一个适当的“包装类”。

如果是这样的话，那么我认为这是一条路。这样，您就可以实现业务逻辑(书籍必须有ISBN)，同时仍然使存储变得非常简单。