Прежде всего, позвольте мне прояснить, что я не прошу никакого кода; Мне просто не нужны общие идеи / рекомендации / мнения о том, как мне реализовать то, что я собираюсь спросить.
Я начинаю создавать систему электронной коммерции онлайн (Yii2 + MongoDB, так что PHP + NoSQL), и есть два требования, которые я не совсем уверен, как реализовать без создания огромного беспорядка как в моем коде, так и в база данных.
Оба реквизита связаны между собой, поэтому я объясню их как один.
Как любая другая серьезная электронная коммерция, у нее были бы категории. А также, как и любая другая серьезная электронная коммерция, каждый продукт будет иметь tags
или же options
, Позвольте мне немного подробнее объяснить, что я называю tags
/options
,
Это доступные параметры, которые пользователь может выбрать при покупке товара, например, цвет или размер, материал и т. Д.
Там будет несколько general
категории, а также другие подкатегории. Например, Electronics
может быть общая категория и подкатегории будут Computers
а также Smart TVs
, Затем, Motherboards
а также 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
]
}
Но:
2. Метки / опции
Вот где настоящая головная боль.
Каждый параметр может принадлежать 0 или более категориям и подкатегориям, поэтому категория Woman fashion
могут быть варианты size
а также color
, но категория Sunglasses
(подкатегория Woman fashion
) мог иметь только color
или даже другой набор опций, полностью отличающийся от Woman fashion
,
Кроме того, значения внутри каждой опции (red
, green
, blue
в color
опция) может появиться в случайных категориях. Так Woman fashion
будет иметь такие цвета, как Strawberry Red
а также Tangerine
, в то время как Cars
будет иметь Carbon
а также Black metallic
,
Также будет несколько типов опций:
size
, который мог быть только S
или же M
, но никогда не оба. В любом случае администратор не сможет написать обычай размер, как Kind of small
; он сможет просто выбрать то, что уже есть в базе данных).colors
что может быть red
или же green
или комбинация цветов, которые выбирает админ).dimensions
или же weight
, в идеале это поля ввода и выпадающие значения для соединения. Например [10]
| (mg||kg|tons)
или же [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
из Product
коллекция).
Или, в качестве альтернативы, вы можете прочитать все категории в память и построить хеш-таблицу с ключом-> categoryId, значением -> [все подкатегории]. Ваши категории обычно не будут часто меняться, и у вас не будет много категорий. Таким образом, все будет хорошо.
Прежде всего, я думаю, что с вашей категорией что-то не так. Women fashion
это что-то общее, вы должны поместить свой продукт в нечто более конкретное, и варианты должны быть там же. Например, может быть, есть категория coat
который имеет size
& color
, Кроме как women fashion
, Пока еще может быть color
вариант в women fashion
потому что это общая характеристика всех подкатегорий.
Если вы думаете об этом, почему все подкатегории организованы в одну родительскую категорию? потому что у них есть что-то общее. Эта общая часть должна быть общими параметрами родительской категории. то есть, должно быть наследование между всеми родительскими категориями и подкатегориями. Например:
женская мода: цвет
пальто: размер
| солнцезащитные очки: форма
затем 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
и т.п.
Еще одна вещь о вариантах. Вы можете указать, какие параметры предполагается использовать для фильтрации продуктов. Например color
определенно один. В то время как dimension
возможно, нет.
О типах опций. С тобой все в порядке, если тебе этого достаточно. У меня есть намного больше типов, как Number
, String
, Single Choice
, Multiple Choices
, Я также планирую реализовать Unit
, Сложная часть Unit
это например
1GB = 1024MB = 1024*1024B
Поэтому, когда вы получаете жесткий диск объемом 1 ГБ и 1 ТБ, вы можете захотеть выполнить преобразование перед фильтрацией продуктов. Это не по теме, я вернусь к вашему вопросу.
Обратите внимание, что хотя варианты разных категорий имеют одно и то же имя. Они вряд ли одно и то же. Material
из Coat
а также Furniture
это 2 разные вещи. Поэтому я склонен определять разные варианты для разных категорий. Таким образом, возможно color
за toys
, а также color
за women fashion
, Это не вступает в противоречие с наследованием, упомянутым выше, поскольку с какого-то уровня подкатегории начинают использовать одни и те же параметры. Это полностью связано с тем, как вы организуете свою структуру категорий. И если вы захотите изменить структуру категории или переместить продукты какое-то время, это будет болезненно. Так что будьте осторожны при определении ваших категорий.
Это все, что приходит мне в голову. Боюсь, я не являюсь носителем английского языка, поэтому вам может быть трудно понять какую-то часть моего ответа. Не стесняйтесь, дайте мне знать.
Других решений пока нет …