我想在ASP.Net MVC网上商店评估文档数据库，可能是mongo db。
一开始有点推理：
大约有200万种产品。
rdbms的产品型号非常糟糕，因为有许多不同类型的产品具有独特的属性。
例如，有些书籍有isbn，作者，标题，页面等，以及有游戏时间，导演，艺术家等的dvds以及更多类型。
最后，我有大约9种不同的产品，它们的组合列数（计算只有标题一次的常用列）大约为70到100，而每个单独的产品最多只有15列。
RDBMS中三种常用的方法是：
如果我想在不同产品的列表中显示书籍的作者（想想开始页面，推荐的产品等），那么EAV模型会有非常糟糕的性能特征并且会使其变得不切实际或表现得更差。忽略列计数并将其全部放在产品表中：虽然我处理的是更大的数据库（行方式），但就表现性能而言，我没有任何超过20列表的经验但我猜100列会产生一些影响。
为每种产品类型创建一个表：我个人不喜欢这种方法，因为它使其他所有产品变得复杂。
C＃驱动程序/类：
我想使用NoRM驱动程序，到目前为止，我想我会尝试创建一个包含所有属性的产品dto（在详细信息类中分组，如书籍详细信息，除了那些应该在列表视图上显示的属性等等。）。
在应用程序中，我将使用BookBehavior / DvdBehaviour，它们是产品dto的包装器，但只暴露了令人羡慕的属性。
我现在的问题：
我对多列方法的性能问题是否有效？
我是否忽视了某些内容，并且在RDBMS中有更好的方法可以做到这一点？
Windows上的MongoDb是否足够稳定？
我使用不同行为包装器的方法是否有意义？
答案 0 :(得分：0)
我对许多列方法的性能问题是否有效？
老实说，我认为表演不是真正的关键问题。如果你有2行100列，那些列永远不会改变，那么SQL Server / MySQL /等实际上会很好。它可能会占用大量不必要的空间，但DB可能会表现得非常好。
DB不会做的是非常容易接受任何更改，我认为这是主要关注点。尝试将列添加到具有2M行的中央表中基本上将是一场噩梦。您可以“分离”单独的字段以分隔子表，但这不一定能解决问题，只是延迟它。 EAV也是一种噩梦，因为你现在需要你的2M行并将它们转换成20M行。
我是否忽视了某些内容，并且在RDBMS中有更好的方法吗？
只要您愿意做出通常的RDBMS牺牲，那么您可能会发现MongoDB对基本CRUD更快，更容易和更灵活。
Windows上的MongoDb是否足够稳定？
我不能这么说。论坛肯定有人在Windows上运行。但对于大多数使用它的人来说，2M记录实际上是小土豆。
我使用不同行为包装器的方法是否有意义？
您是否建议如下？
如果是这样，那么我认为这是要走的路。通过这种方式，您可以实现业务逻辑（书籍必须具有ISBN），同时仍然可以使存储变得非常简单。