mongodb 连锁店数据库设计

mongodb DB design for shop chain

使用mongo。该应用程序需要允许在不同类型的位置购物。商店共享他们提供的一些产品,有些是独一无二的。每个商店为每个产品设置自己的价格(很多可能是相同的价格,但目前还不清楚,可能不是)。

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

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

但是如何为这个关联建模呢?如果我有一个 PriceList,我引用了一个 Product(例如,通过 ID),那么在浏览产品时,生成商店价目表不会产生巨大的开销吗? pricelist.length 查询 Product 模型的名称及其类别的查询数量?

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

还有其他建议吗?

这样的事情怎么样:

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


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

请注意,Pricelist 中的 15 指的是产品 ID。这样一来,每个店铺都可以为自己的产品定价。

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

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

NoSQL 在设计上没有采用相同的连接方式,因此它并不总是最合适的。而是根据 "documents" 和集合来考虑数据。 NoSql 在分层数据方面做得很好,但在许多情况下,数据必须重复。

如果商店及其 products/prices 之间存在大量重复数据,那么最好使用常规关系数据库。

如果您仍想使用 MongoDB,您有两个选择。

  1. 将 product/pricing 数据与每个商店文件放在一起,并且可以接受可能重复的数据。
  2. 将 product/pricing 数据放在一个单独的集合中,并在每个商店需要时查询它。

当然这取决于您的体系结构,但我倾向于上面的 #2,因为您总是可以同时将查询与商店列表结合起来并以这种方式进行优化。如果您的数据增长,拆分设计在 long-运行 中也可能更好。如果这两个集合变得足够大,您可以轻松地将它们放在不同的节点上并查看 MongoDB.

背后的真正力量

祝你好运!