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

2022-01-07 00:00:00 mongodb nosql php yii2

首先，让我明确一点，我不要求任何代码；我只是想要一些关于如何实施我将要提出的问题的一般性想法/指导/意见.

First of all, let me make clear that I'm not asking for any code; I just wan't some general ideas/guidance/opinions about how could I implement what I'm about to ask.

我正在开始构建一个在线电子商务系统(Yii2 + MongoDB，所以，PHP + NoSQL)，并且有两个必要条件我不完全确定如何在不造成巨大混乱的情况下实现我的代码和数据库.

I'm starting to build an online e-commerce system (Yii2 + MongoDB, so, PHP + NoSQL), and there are two requisites that I'm not entirely sure how to implement without creating a huge mess in both my code and the database.

这两个必要条件是相关的，所以我将把它们解释为一个.

Both requisites are related, so I'll explain them both as one.

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

As any other serious e-commerce, it would have categories. And also, as any other serious e-commerce, each product will have tags or options. Let me explain a little bit further what I call tags/options.

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

Those are the available options that a user could select when buying a product, for example, the color or the size, the material, etc.

  1. 类别

将有多个 general 类别以及其他子类别.例如，Electronics 可以是一般类别，而子类别可以是 Computers 和 Smart TVs.那么，Motherboards 和 RAM 可以是 Computers 的子类别.

There would be multiple general categories as well as other sub-categories. For example, Electronics could be a general category and sub-categories would be Computers and Smart TVs. Then, Motherboards and RAM could be sub-categories of Computers.

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

This by itself could be easily stored in a database, but here it goes the problem:

  • 每个产品在列出它所属的任何类别或上层类别时都应该出现.这意味着如果我(作为最终用户)浏览Computers 类别中的所有项目，我应该看到属于子类别Graphic card 的NVIDIA GTX670类别计算机的code>.
  • Each product should appear when listing any of the categories it belongs to, or the upper categories. That means that if I (as the final user) browse all the items in Computers category, I should see NVIDIA GTX670 which belongs to the subcategory Graphic cards of the category Computers.

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

I could save each product the following way:

{
    _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
    ]
}

但是:

  • 我不确定检索某个类别的所有项目(当然还有所有子类别的项目)的查询速度有多快.
  • 我不确定该方法还有哪些其他缺点，因此，请随时推荐用于存储此内容的任何替代架构.


2. 标签/选项

这才是真正令人头疼的地方.

This is where the real headache is.

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

Each option could belong to 0 or more categories and subcategories, so the category Woman fashion could have the options size and color, but the category Sunglasses (subcategory of Woman fashion) could have only color, or even another set of options, completely different from Woman fashion.

此外，每个选项中的值(red、green、blue 在 color 选项中)可以出现在随机类别中.所以Woman fashion会有Strawberry Red和Tangerine这样的颜色，而Cars会有Carboncode> 和 黑色金属.

Furthermore, the values inside each option (red, green, blue in the color option) could appear in random categories. So Woman fashion would have colors like Strawberry Red and Tangerine, while Cars would have Carbon and Black metallic.

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

Also, there would be several types of options:

  • 完全静态(如size，只能是S 或M，但不能同时是两者.无论如何，管理员不会无法编写自定义大小，例如Kind of small；他只能选择数据库中已有的内容).
  • 可以组合在一起的静态(如 colors，可以是 red 或 green，或者管理员选择的颜色组合).
  • 自由输入(如 dimensions 或 weight，理想情况下，它是要加入的输入字段和下拉值.例如 [10] | (mg||kg|tons) 或 [20] (cm|m|km|miles)).莉>
  • Completely static (like size, which could be only S or M, but never both. In any case, the administrator won't be able to write a custom size, like Kind of small; he would be able to just select what it's already in the database).
  • Static that can combine together (like colors, which could be red or green, or a combination of colors that the admin chooses).
  • Free-input (like dimensions or weight, that would, ideally, be input fields and dropdown values to join with. For example [10] | (mg||kg|tons) or [20] (cm|m|km|miles)).


我可以像这样保存每个选项:


I could save each option like this:

{
    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 个类别并且选项的每个值都设置为出现在随机类别中时.
另外我只是觉得它不够干净，但也许这只是我自己.

But I'm worried about how big a single option could turn to be, when there are 30 categories and each value of the option is set to appear in random categories.
Also I just don't see it clean enough, but maybe that is just me.

无论如何，与前一点一样，请随时提出任何可以提出的建议，我将不胜感激您能给我的任何反馈.

Anyways, as with the previous point, please feel free to suggest anything to can come up with, I'll greatly appreciate any feedback that you can give me.

推荐答案

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

I'm running a e-commerce website, too. Here's my advice on how I implement the features you mentioned. Hope it helps.

  • 类别

我将它们组织成一个扁平的结构，在你的情况下是:

I organize them in a flat structure, in your case it would be:

    {_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/", ...}

产品现在只需要在叶子类别中.在你的情况下:

And the product now needs to be only in the leaf categories. In your case:

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

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

The product can be in multiple categories of course, so the categoryIds remains an array. Here's the tricky part. When you list the Electronics category, you can find all its subcategories by:

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

idPath 索引在这里工作，所以它会很快.当你找到所有的子类别时，你可以很容易地找到其中的所有产品(在Product集合的categoryIds上建立索引).

idPath index works here so it's going to be fast. when you find out all the sub-categories, you can easily find all the products in them (build index on the categoryIds of Product collection).

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

Or alternatively, you can read all the categories into memory and build a hash table with the key->categoryId, value->[all the subcategories]. Your categories usually won't change frequently and you won't have a lot of categories. Thus it's going to be fine.

  • 标签/选项

首先，我认为您的类别有问题.女性时尚 是通用的东西，你应该把你的产品放在更具体的东西上，选项也应该在那里.例如，可能有一个类别 coat 具有 size &color，除了女性时尚.虽然在 women fashion 中可能仍然有 color 选项，因为它是所有子类别的共同特征.
如果您考虑一下，为什么所有子类别都组织在一个父类别中?因为他们有共同点.该公共部分应该是父类别的公共选项.也就是说，所有的父类和子类之间应该有继承关系.例如:

First of all I think there's something wrong with your category. Women fashion is something generic, you should put your product into something more specific, and the options should be there too. For example, there maybe a category coat which has the size & color, other than women fashion. While there may still be color option in women fashion because it's a common characteristic of all subcategories.
If you think about it, why all the subcategories are organized in one parent category? because they have something in common. That common part should be the common options of the parent category. that is to say, there should be a inheritance between all the parent category and subcategories. For example:

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

women fashion: color
|-coat: size
|-sun glasses: shape

然后 coat 最终会有 2 个选项 color &<代码>尺寸.太阳镜:颜色 &形状.当您查看women fashion 时，只有1 个选项color.它也过滤子类别，因为它们继承自 women fashion.
至于颜色的取值，我的想法是只用标准色Strawberry Red其实是red，Tangerine其实是orange.当您过滤产品时，您真的不希望它们出现.否则选项太多，绝对不利于用户体验.
但是，除了类别中的 color 选项之外，我的网站还有一些叫做 customizable options 的东西.这些选项仅在产品上定义.当您查看类别时，它们永远不会出现.在这里你可以有草莓红 &橘子.在我看来，这些不是产品的天然"特性.它们仅用于使用户在查看产品时感觉更舒适.因此，您也可以选择这样的选项，例如 Tangerine with figure 等.
关于选项的另一件事.您可能想要标记哪些选项应该用于过滤产品.例如 color 绝对是其中之一.而 dimension 可能不是.

Then coat would finally has 2 options color & size. sun glasses: color & shape. When you are viewing women fashion, there's only 1 option color. It filters the subcategories too because they inherit from women fashion.
As to the values of color, my idea is only use the standard colors Strawberry Red is actually red, Tangerine is actually orange. You don't really want them to appear when you filter the products. Otherwise there would be too many options, definitely not good for user experience.
However, besides color option from the category, my site also has something called customizable options. These options are only defined on the products. They never appear when you viewing category. Here you can have Strawberry Red & Tangerine. In my opinion, these are not 'natural' properties of a product. They are only used to make the user feel more comfortable when viewing the product. Thus also you can have option of this kind like Tangerine with figure etc.
One more thing about options. you may want to mark which options are supposed to be used for filtering products. For example color is definitely one. While dimension may be not.

关于选项类型.如果对你来说足够了，你的就可以了.我有更多类型，例如Number、String、Single Choice、Multiple Choices.我还计划实施Unit.Unit 的棘手部分是例如

About types of options. Yours are fine if it's enough for you. I have a lot more types like Number, String, Single Choice, Multiple Choices. I also plan to implement the Unit. Tricky part of Unit is that for example

1GB = 1024MB = 1024*1024B

所以当你拿到1GB和1TB的硬盘时，你可能想在过滤产品之前做一个转换.这不是主题，我会回到你的问题.

So when you get a hard disk of 1GB and 1TB, you may want to do a conversion before filtering products. This is off the topic I'll get back to your question.

请注意，虽然不同类别的选项名称相同.它们不太可能是同一回事.Coat 和 Furniture 的 Material 是两种不同的东西.所以我倾向于为不同的类别定义不同的选项.因此，toys 可能有color，女性时尚 可能有color.这与上面提到的继承并不冲突，因为从某个层面来看，子类别开始共享相同的选项.这与您如何组织类别结构完全相关.如果你想改变品类结构或移动产品一段时间，那将是痛苦的.所以在定义类别时要小心.

Note that although the options of different categories have the same name. They are not likely the same thing. Material of Coat and Furniture are 2 different things. So I tend to define different options for different categories. Thus there maybe color for toys, and color for women fashion. This does not conflict with the inheritance mentioned above because from some level, the subcategories begin to share the same options. This is completely related to how you organize your category structure. And if you want to change category structure or move products some time, it would be painful. So be careful when you define your categories.

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

That's all that comes up in my mind. I'm afraid I'm not native English speaker thus you may find some part of my answer hard to understand. Feel free to let me know.

相关文章