保存，组织和查询产品，选项/标签和类别 [英] Saving, organizing and querying products, options/tags and categories

问题描述

首先，请让我明确说明我没有要求任何代码；我只是对如何实施我要问的问题没有任何一般性想法/指导/意见.

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类别中的所有项目，则应该看到NVIDIA GTX670属于类别Computers的子类别Graphic cards.

• 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. 标签/选项

2. Tags/options

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

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.

此外，每个选项(color选项中的red，green，blue)内的值可能会出现在随机类别中.因此Woman fashion将具有Strawberry Red和Tangerine之类的颜色，而Cars将具有Carbon和Black metallic的颜色.

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)). /li>

• 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.

• 标签/选项

首先，我认为您的类别存在问题. Women fashion是通用名称，您应该将产品放在更特定的名称中，并且选项也应该存在.例如，类别coat可能具有size& color，而不是women fashion.虽然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:

妇女的时尚:颜色
| -coat:尺寸
|-太阳眼镜:形状

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

然后coat最终将有2个选项color& size. sun glasses:color& shape.当您查看women fashion时，只有一个选项color.它也过滤子类别，因为它们继承自women fashion.
至于颜色的值，我的想法是仅使用标准颜色Strawberry Red实际上是red，Tangerine实际上是orange.您真的不希望它们在过滤产品时出现.否则，会有太多选择，这绝对不利于用户体验.
但是，除了类别中的color选项之外，我的网站还具有名为customizable options的内容.这些选项仅在产品上定义.当您查看类别时，它们永远不会出现.在这里您可以拥有Strawberry Red& Tangerine.我认为这些不是产品的自然"属性.它们仅用于使用户在查看产品时感到更舒适.因此，您也可以选择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，对于women fashion可能存在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.

这篇关于保存，组织和查询产品，选项/标签和类别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！