首先,让我明确一点,我不要求任何代码;我只是想要一些关于如何实施我将要提出的问题的一般性想法/指导/意见.
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.
将有多个 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>.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
会有Carbon
code> 和 黑色金属
.
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)
).莉>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).colors
, which could be red
or green
, or a combination of colors that the admin chooses).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