商店连锁店的mongodb DB设计

Question

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

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

然后，通过将价格与每个Product 相关联，为每个商店创建一个PriceList，从而为特定商店提供他们实际销售的产品。

但是如何建模这种关联呢？如果我有一个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"
}

请注意，Pricelist 中的 1 和 5 指的是产品 ID。这样，每个商店都可以为产品设置自己的价格。