fla*_*ave 5 non-relational-database mongodb e-commerce database-schema
我的目标是拥有具有一些基本信息的产品，例如
并且每个产品都可以有基于以下的选项：
我读过几篇文章，但找不到适合我问题的答案，即如何反映所有这些可能的选项组合可以有不同的 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
},
...
],
}
但不知何故，我觉得可能有一种更简单的方法来完成我正在寻找的事情。
产品信息的数据建模与其说是一门科学，不如说是一门艺术。
\n将产品定义为销售所考虑的实体是很常见的。比如说汽车模型或电缆。例如“cat 5e 以太网电缆”。
\n这样的产品有属性和维度。属性可能是
\n属性往往因行业而异，甚至同一家公司的不同产品类别之间也会有所不同。
\n尺寸区分产品的不同变体。一个或多个维度可以定义一个具体的产品。典型尺寸是尺寸和颜色。对于电缆，我们可能有：
\n因此，产品是您的一种商品的概念。在纸质目录中，产品通常被描述为单个事物（可能在一页上）。例如，夹克有蓝色和棕色，尺码为 S、M、L 和 XL。
\n单一产品的定义有些模糊。蓝色和绿色运动鞋可能是同一产品，但橙色和金色可能不会被视为同一产品。
\n在电子商务出现之前，我们倾向于期望产品所有尺寸的价格相同 - 不久前，如果 8 码的鞋子比 9 码的鞋子贵，人们会感到震惊。
\n沿着某些维度（主要是颜色），用户通常除了图片之外。其他尺寸（例如鞋码）通常不需要特定的图片。
\n对于某些产品，制造商可能被认为是一个维度（电缆），对于其他产品，它可能被认为是无关的（扎带），而对于其他产品，来自不同制造商的两个外观相同的商品可能被认为是完全不同的产品（例如运动鞋）。
\n另一个概念是SKU——库存单位是仓库中实际存在的东西。通常，我们将每个产品的尺寸与其他 SKU 相乘。因此，有 5 种尺寸 x 3 种颜色 x 2 种阻燃变体 - 因此可能有 30 个 SKU。通常每个 SKU 都有一个不同的 GTIN/UPC/EAN（“条形码”4423456789012）。
\n将 SKU 和产品分开是最佳实践，因为它们涉及不同的关注点： 产品对于营销和销售非常重要。SKU 涉及审计、簿记和物流。产品代表概念，SKU代表实物商品。库存量通常应保留在 SKU 中或附近 - 因为在大型商业应用程序中，它可能每秒更新几次。我永远不会设计一个交易数据（库存量）与主数据（产品描述等）混合的系统。
\n定价信息历来附加在产品上，因为产品和价格数据有些静态，但动态定价可能会改变这种情况。
\n您似乎要求提供产品数据库。无模式数据库非常适合此目的，因为很难预测未来几年所需的所有维度。对关系数据库的整个事情进行规范化当然可以完成，但往往会导致代码不太优雅且缓慢。
\n{\n name: "Cat 5e Cable",\n \xe2\x80\xa6\n dimensions: {\n color: {\n title: "Color", \n red: {\n title: "Red",\n images: [\n "http://myserver.com/images/product_12345_3",\n "http://myserver.com/images/product_12345_4",\n ],\n },\n green: { \xe2\x80\xa6 }\n },\n size: {\n title: "Size"\n s05: {\n title: "0.5 m",\n images: [],\n },\n s1: {...},\n fireretardant: \n title: "Size"\n yes: {\n title: "fire retardant",\n images: [],\n },\n no: {\n title: "not fire retardant",\n images: [],\n }\n }\n // here you need a stable way of generating keys from dimension data \n variations: [\n {\n dimensions: {color: red, size: s1, fireretardant: no}\n SKU: "98765"\n price: 10,\n },\n {\n dimensions: {color: red, size: s1, fireretardant: yes}\n SKU: "98765"\n price: 10,\n },\n },\n \xe2\x80\xa6\n]\n我已经用这样的模式实现了应用程序。通常，您希望在管理 GUI 中限制可用维度和每个维度的有效值，以便工作人员不会一直想出晦涩的新维度。但这应该是一种管理限制，而不是底层架构之一。
\n不存在的组合（“阻燃剂仅在绿色中可用，而在 0.5 m 中不可用），冲突的指令（“使所有 5 m 电缆为 10 \xe2\x82\xac，所有红色电缆为 8 \xe2\x82\xac”），不同且不一致的想法，例如需要图像、尺寸之间应共享哪些图像、不一致的定义、什么被视为单独的产品（“USB C”或只是一个变体（“3.5 毫米或 5.5 毫米耳机插孔”）、翻译和转换（别让我从鞋码开始）让现实生活中的数据库设计和维护变得有趣\xe2\x80\xa6\n这就是所谓的“领域知识”。你需要让鞋子推销员参与来设计一个好的鞋子数据库。
\n| 归档时间： |
|
| 查看次数： |
10185 次 |
| 最近记录： |