保存、组织和查询产品、选项/标签和类别

首先，让我澄清一下，我并不是要求任何代码；而是要求任何代码。我只是想要一些关于如何实现我要问的问题的一般想法/指导/意见。

我开始构建一个在线电子商务系统（Yii2 + MongoDB，所以，PHP + NoSQL），有两个先决条件我不完全确定如何实现而不在我的代码和应用程​​序中造成巨大的混乱。数据库。

这两个要求都是相关的，所以我将把它们作为一个来解释。

与任何其他严肃的电子商务一样，它也有类别。而且，与任何其他严肃的电子商务一样，每种产品都会有tags or options。让我进一步解释一下我所说的tags/options.

这些是用户在购买产品时可以选择的可用选项，例如颜色或尺寸、材料等。

1. 类别

会有多个general类别以及其他子类别。例如，Electronics可以是一般类别，子类别可以是Computers and Smart TVs. Then, Motherboards and RAM可以是子类别Computers.

这本身可以很容易地存储在数据库中，但问题就在这里：

• 每个产品在列出其所属的任何类别或上层类别时都应出现。这意味着如果我（作为最终用户）浏览了中的所有项目Computers类别，我应该看看NVIDIA GTX670属于子类别Graphic cards该类别的Computers.

我可以通过以下方式保存每个产品：

{
    _id: asdasfwetrw34tw34t245y45y,
    name: "NVIDIA GTX670",
    price: 99.50,
    ...
    ...
    categories: [
        "Electronics", //<-- just the ID of that group
        "Computers", //<-- just the ID of that group
        "Graphic cards" //<-- just the ID of that group
    ]
}

But:

• 我不确定检索某个类别的所有项目（当然还有所有子类别的项目）的查询有多快。
• 我不确定该方法还有什么其他缺点，因此，请随意推荐任何替代模式来存储它。

2. 标签/选项

这才是真正让人头疼的地方。

每个选项可以属于 0 个或多个类别和子类别，因此类别Woman fashion可以有选择size and color，但是类别Sunglasses（子类别Woman fashion) 只能有color，甚至是另一组选项，完全不同于Woman fashion.

此外，每个选项中的值 (red, green, blue in the color选项）可能出现在随机类别中。所以Woman fashion会有像这样的颜色Strawberry Red and Tangerine, while Cars将有Carbon and Black metallic.

此外，还有几种类型的选项：

• 完全静态（如size，这可能只是S or M，但绝不会两者兼而有之。在任何情况下，管理员都无法编写自定义尺寸，例如Kind of small;他将能够只选择数据库中已有的内容）。
• 可以组合在一起的静态（例如colors，这可能是red or green，或管理员选择的颜色组合）。
• 自由输入（如dimensions or weight，理想情况下，这将是要连接的输入字段和下拉值。例如[10] | (mg||kg|tons) or [20] (cm|m|km|miles)).

我可以这样保存每个选项：

{
    option: "Color",
    type: "Static with combinations"
    values: [
        {
            value: "Red",
            categories: [
                "Sunglasses"
            ]
        },
        {
            value: "Green",
            categories: [
                "Sunglasses",
                "T-Shirts"
            ]
        },
        {
            value: "Black metallic",
            categories: [
                "Cars"
            ]
        }
    ],
    categories: [
        "Woman fashion", //<-- only the ID of this group
        "Cars" //<-- only the ID of this group
    ]
}

但我担心当有 30 个类别并且选项的每个值都设置为出现在随机类别中时，单个选项会变得有多大。
而且我只是觉得它不够干净，但也许这只是我的情况。

无论如何，与上一点一样，请随时提出任何建议，我将非常感谢您给我的任何反馈。

我也在经营一个电子商务网站。这是我关于如何实现您提到的功能的建议。希望能帮助到你。

• 类别

我以扁平结构组织它们，在你的情况下它是：

    {_id: 1, name: "Electronics", parentId: 0, idPath: "/0/1/" ...}
    {_id: 2, name: "Computers", parentId: 1, idPath: "/0/1/2/", ...}
    {_id: 3, name: "Graphic Cards", parentId: 2, idPath: "/0/1/2/3/", ...}

现在该产品只需位于叶子类别中。在你的情况下：

    {
        _id: asdasfwetrw34tw34t245y45y,
        name: "NVIDIA GTX670",
        price: 99.50,
        ...
        ...
        categoryIds: [3]
    }

当然，产品可以属于多个类别，因此categoryIds仍然是一个数组。 这是棘手的部分。当您列出Electronics类别，您可以通过以下方式找到其所有子类别：

    db.categories.find({idPath: /^\/0\/1/})

idPath索引在这里工作，所以它会很快。当你找到所有的子类目后，你就可以很容易地找到其中的所有产品（在子类目上建立索引）categoryIds of Product收藏）。

或者，您可以将所有类别读入内存，并使用 key->categoryId、value->[所有子类别] 构建一个哈希表。您的类别通常不会经常更改，并且您不会有很多类别。这样就会好起来的。

• 标签/选项

首先我认为你的类别有问题。Women fashion是通用的东西，你应该把你的产品变成更具体的东西，而且选项也应该在那里。例如，可能有一个类别coat其中有size & color， 以外women fashion。虽然可能仍然存在color选项中women fashion因为这是所有子类别的共同特征。
如果您想一想，为什么所有子类别都组织在一个父类别中？因为他们有一些共同点。该公共部分应该是父类别的公共选项。也就是说，所有的父类和子类之间应该有继承关系。例如：

女性时尚：色彩
|-外套：尺寸
|-太阳镜：形状

Then coat最终有2个选择color & size. sun glasses: color & shape。当您观看时women fashion,只有1个选择color。它也过滤子类别，因为它们继承自women fashion.
至于颜色的值，我的想法是只使用标准颜色Strawberry Red实际上是red, Tangerine实际上是orange。您确实不希望它们在过滤产品时出现。否则选项太多，肯定不利于用户体验。
然而，除此之外color从类别中选择，我的网站也有一个叫做customizable options。这些选项仅在产品上定义。当您查看类别时，它们永远不会出现。在这里你可以拥有Strawberry Red & Tangerine。在我看来，这些都不是产品的“天然”特性。它们仅用于让用户在查看产品时感觉更舒适。因此你也可以有这样的选择Tangerine with figure etc.
关于选项的另一件事。您可能想要标记哪些选项应该用于过滤产品。例如color绝对是其中之一。尽管dimension也许不会。

关于选项的类型。如果对你来说足够的话，你的就很好。我还有很多类型，比如Number, String, Single Choice, Multiple Choices。我还计划实施Unit。棘手的部分Unit例如

1GB = 1024MB = 1024*1024B

所以当你拿到1GB和1TB的硬盘时，在筛选产品之前你可能需要做一下换算。这不是主题，我会回到你的问题。

请注意，虽然不同类别的选项具有相同的名称。它们不太可能是同一件事。Material of Coat and Furniture是两个不同的东西。所以我倾向于为不同的类别定义不同的选项。因此也许有color for toys, and color for women fashion。这与上面提到的继承并不冲突，因为从某种程度上，子类别开始共享相同的选项。这与你如何组织类别结构完全相关。而如果你想改变品类结构或者转移产品一段时间，那就会很痛苦。因此，定义类别时要小心。

这就是我脑海中浮现的一切。恐怕我的母语不是英语，因此您可能会发现我的回答的某些部分难以理解。请随时告诉我。