mongodb DB连锁店设计

Question

使用mongo。该应用程序需要允许在不同类型的位置购物。商店在他们的报价中共享一些产品，有些是独一无二的。每家商店为每种产品设定自己的价格（许多可能是相同的价格，但目前尚不清楚，可能不是）。

我到目前为止的做法是创建一个Product模型，它只有名称，描述和类别。

然后，对于每个商店，将创建一个PriceList，方法是将价格与每个Product相关联，从而仅为特定商店购买他们实际销售的产品。

但是如何模拟这种关联？如果我有一个PriceList，我参考Product（例如通过ID），那么当浏览产品时，这不会产生巨大的开销，因为生成该商店的价格表将会有pricelist.length查询量的Product模型名称及其类别？

我的另一个想法是让每个价格表都有一个包含名称，描述，类别和价格的所有产品的清单，但是为一家新商店生成新的价格表似乎很麻烦，因为没有独立的Product列表从哪个项目复制？

还有其他建议吗？

Answer 1

您可能已经考虑过这一点，但以防万一您需要确保使用NoSQL数据库（如MongoDB）是您的问题的正确解决方案。

使用RDBMS的好处是您可以规范化数据并轻松进行连接。因此，一个表中的产品在另一个表中定价，并运行查询并从两个表中提取数据。这听起来像你已经从这个世界来了，可能理解了联接的概念。

NoSQL没有按照设计方式加入，因此它并不总是最合适的。数据被认为是“文档”和集合。 NoSql在分层数据方面做得很好，但在很多情况下，数据必须重复。

如果您在商店及其产品/价格之间有大量重复数据，那么使用常规关系数据库可能是最好的选择。

如果你还想使用MongoDB，你有两个选择。

1. 把产品/定价数据与每个店铺文件并确定可能复制数据。
2. 将产品/定价数据放入单独的集合中，并在每个商店需要时查询。

当然这取决于你的架构，但我会倾向于上面的＃2，因为你总是可以同时将查询与商店列表结合起来，并以这种方式进行优化。如果数据增长，分拆设计在长期运行中可能会更好。如果这两个集合足够大，您可以轻松将它们放在不同的节点上，并查看MongoDB背后的真正威力。

祝你好运！

Answer 2

怎么是这样的：

Shop = { 
    "Pricelist": { 
        "1": 2.99, 
        "5": 3.99 
       } 
} 


Product = { 
    "id": "1", 
    "name" : "Lego" 
} 

注意1和5内Pricelist参考产品的ID。通过这种方式，每家商店都可以为产品设定自己的价格。