MongoDB模式适用于具有不同SKU、价格和库存的电子商务产品 [英] MongoDB Schema for ecommerce products that have variations with different SKUs, prices and stock

问题描述

我的目标是拥有具有如下基本信息的产品

• 名称
• 说明
• 品牌/制造商
• 尺寸和重量

并且每个产品都可以有基于

的选项

• 大小
• 颜色
• 材料

我读了几篇文章，但找不到合适的答案来解决我的问题，即如何反映所有这些可能的选项组合可能有不同的SKU、价格和库存金额。 另外，我想为一个产品的不同颜色有不同的图像。

所以我现在的想法是对所有选项都有单独的集合：

• 大小
• 颜色
• 材料

产品文档中所有这些选项的指针数组和附加的variations数组，它反映了选项的每一种可能组合，并添加了SKU、price和stock字段。

{
  _id: "12345",
  name: "My Product",
  ...
  colors: [
    {
      _id: "Color_1",
      images: [
        "http://myserver.com/images/product_12345_1",
        "http://myserver.com/images/product_12345_2",
      ]
    },
    {
      _id: "Color_3",
      images: [
        "http://myserver.com/images/product_12345_3",
        "http://myserver.com/images/product_12345_4",
      ]
    }
  ],
  sizes: [
    {
      _id: "Size_5"
    },
    {
      _id: "Size_9"
    }
  ],
  materials: [
    {
      _id: "Material_2"
    }
  ],
  variations: [
    {
      color: "Color_1",
      size: "Size_5",
      material: "Material_2",
      SKU: "98765"
      price: 10,
      stock: 2
    },
    {
      color: "Color_1",
      size: "Size_9",
      material: "Material_2",
      SKU: "87654"
      price: 11,
      stock: 5
    },
    ...
  ],
}

但不知何故，我觉得可能有一种更容易的方法来实现我想要的东西。

推荐答案

产品信息的数据建模与其说是一门科学不如说是一门艺术。

将产品定义为销售人员考虑的实体是很常见的。比方说一个汽车模型或一根电缆。例如，CAT 5E以太网电缆(&Q)。

此类产品具有属性和维度。属性可能是

• 标准/规范(如EIA/TIA-586)
• 制造商(Kabelwerk Eupen)
• 线数(8)
• 包装(塑料袋)
• 标签(网络、以太网、布线、基础设施)
• ROOS(符合)
• 等

不同行业的属性往往不同，甚至同一公司不同产品类别之间的属性也不同。

尺寸区分产品的不同变体。一个或多个维度可以定义具体产品。典型的尺寸是大小和颜色。对于电缆，我们可能有：

• 大小/长度(0.5、1、2、5、10米)
• 颜色(绿色、红色、蓝色)
• 阻燃剂(是，否)

所以产品是你的一种商品的概念。在纸质目录中，产品通常被描述为单一的东西(可能在一页上)。例如，有S、M、L和XL尺码的蓝色和棕色夹克。

单一产品的定义有些模糊。蓝色和绿色的运动鞋可能是同一种产品，但橙色和金色可能不被视为相同的产品。

在电子商务之前，我们倾向于期望产品的所有尺寸都有相同的价格--不久前，人们还对8码的鞋比9号的鞋更贵感到震惊。

沿着一些维度--主要是颜色--用户通常不包括图片。至于其他尺寸--比如鞋码--通常不会出现具体的图片。

对于某些产品，制造商可能被认为是一个维度(电缆)，对于其他产品，它可能被认为是无关紧要的(电缆)，而对于其他产品，来自不同制造商的两个外观相同的商品可能被视为完全不同的产品(例如运动鞋)。

另一个概念是SKU-库存单位是实际在仓库中的物品。通常情况下，每个产品的尺寸都会与其他SKU相乘。因此，5个尺寸x 3个颜色x 2个阻燃变种-因此可能有30个SKU。通常，每个SKU都有不同的GTIN/UPC/EAN(条形码和4423456789012)。

将SKU和产品分开是最佳实践，因为它们涉及不同的关注点：产品对市场营销和销售都很重要。SKU涉及审计、簿记和物流。产品代表概念，SKU代表实物。库存数量通常应该保存在SKU中或附近-因为在大型商业应用程序中，它可能每秒更新几次。我永远不会设计一个交易数据--库存量--与主数据--产品描述等--混为一谈的系统。

定价信息过去一直附加到产品，因为产品和价格数据在某种程度上是静态的，但动态定价可能会改变这一点。

您似乎在请求产品数据库。无模式数据库很好地实现了这一点，因为很难预测未来几年所需的所有维度。关系数据库的标准化当然是可以完成的，但结果不是很美观，而且会降低代码的速度。

{
  name: "Cat 5e Cable",
  …
  dimensions: {
    color: {
       title: "Color", 
       red: {
          title: "Red",
          images: [
            "http://myserver.com/images/product_12345_3",
            "http://myserver.com/images/product_12345_4",
          ],
        },
        green: { … }
    },
    size: {
      title: "Size"
      s05: {
        title: "0.5 m",
        images: [],
      },
      s1: {...},
    fireretardant:           
      title: "Size"
      yes: {
        title: "fire retardant",
        images: [],
      },
      no: {
        title: "not fire retardant",
        images: [],
      }
  }
  // here you need a stable way of generating keys from dimension data    
  variations: [
    {
      dimensions: {color: red, size: s1, fireretardant: no}
      SKU: "98765"
      price: 10,
    },
    {
      dimensions: {color: red, size: s1, fireretardant: yes}
      SKU: "98765"
      price: 10,
    },
  },
  …
]

我已经使用这样的模式实现了应用程序。通常，您希望在管理图形用户界面中限制可用的维度和每个维度的有效值，这样员工就不会一直想出晦涩难懂的新维度。但这应该是管理限制，而不是基础架构之一。

不存在的组合(阻燃剂只有绿色的，没有0.5米的)，相互矛盾的说明(使所有5米长的电缆10欧元，所有的红色电缆8欧元&)，不同和不一致的想法，例如需要图像，哪些图像应该在不同的维度之间共享，不一致的定义，什么被认为是单独的产品(USBC)或只是一个变体(&3.5 mm或5.5 mm耳机插孔)，翻译和转换(不要让我从鞋码开始)使现实生活中的数据库设计和维护变得有趣… 这就是所谓的领域知识。您需要让鞋类销售员参与设计一个好的鞋类数据库。

这篇关于MongoDB模式适用于具有不同SKU、价格和库存的电子商务产品的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！