代码之家 › 专栏 › 技术社区 › Maxem

Web商店架构-文档数据库

database mongodb c#

Maxem · 技术社区 · 15 年前

我想评估一个文档数据库,可能是ASP.NET MVC网上商店中的MongoDB。

一开始有点道理:

大约有200万种产品。

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

例如,有书号、作者、书名、书页等书籍,还有DVD,有播放时间、导演、艺术家等,还有相当多的类型。

最后,我将得到大约9种不同的产品,它们的组合列数(像标题这样的普通列只计算一次)大约为70到100,而每种产品最多有15列。

RDBMS中常用的三种方法是:

EAV模型,如果我想把一本书的作者显示在一个不同产品的列表中(想想开始页,推荐的产品等),它将具有非常糟糕的性能特征,并且会使它变得不切实际或性能更差。

忽略列数并将其全部放在产品表中:尽管我处理的数据库比较大(按行),但就性能而言,我对超过20列的表没有任何经验,但我想100列可能会有一些影响。

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

C驱动程序/类:

我想使用norm驱动程序,到目前为止,我想我将尝试创建一个包含所有属性的产品DTO(分组在细节类中,如book details,应该在列表视图中显示的属性除外)。

在应用程序中,我将使用BookBehavior/dvdbehavior,它是围绕产品DTO的包装纸,但只公开相关属性。

我现在的问题:

1 回复 | 直到 7 年前

Gates VP 15 年前

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

老实说,我不认为绩效真的是关键问题。如果有200行100列,而这些列从未更改过,那么SQL Server/MySQL/etc实际上会做得很好。它可能会占用大量不必要的空间,但数据库的性能可能会很好。

数据库不会做的是 接受任何更改 很容易,我认为这是中心问题。试图将列添加到一个有2米行的中央表中,基本上是一场噩梦。您可以将单独的字段“分包”到单独的子表中,但这并不一定能解决问题,只是延迟了问题。EAV也是一个噩梦,因为你现在把你的2米排变成20米排。

我是否忽略了一些东西,并且有更好的方法在RDBMS中实现它?

只要您愿意牺牲通常的RDBMS,那么您可能会发现MongoDB对于基本CRUD来说更快、更容易、更灵活。

Windows上的MongoDB是否足够稳定?

我不能这么说。论坛上肯定有人在Windows上运行。但是对于大多数使用它的人来说,200万的记录实在是小菜一碟。

我处理不同行为包装的方法有意义吗?

你是在建议以下内容吗?

如果是这样的话,我想这就是我们要走的路。这样,您就可以实现业务逻辑(书籍必须具有ISBNS),同时仍然使存储变得非常简单。