Сохранение, организация и запрос продуктов, опций / тегов и категорий

Прежде всего, позвольте мне прояснить, что я не прошу никакого кода; Мне просто не нужны общие идеи / рекомендации / мнения о том, как мне реализовать то, что я собираюсь спросить.

Я начинаю создавать систему электронной коммерции онлайн (Yii2 + MongoDB, так что PHP + NoSQL), и есть два требования, которые я не совсем уверен, как реализовать без создания огромного беспорядка как в моем коде, так и в база данных.

Оба реквизита связаны между собой, поэтому я объясню их как один.

Как любая другая серьезная электронная коммерция, у нее были бы категории. А также, как и любая другая серьезная электронная коммерция, каждый продукт будет иметь tags или же options, Позвольте мне немного подробнее объяснить, что я называю tags/options,

Это доступные параметры, которые пользователь может выбрать при покупке товара, например, цвет или размер, материал и т. Д.

  1. категории

Там будет несколько 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 категорий, и каждое значение параметра должно отображаться в случайных категориях.
Кроме того, я просто не вижу этого достаточно чистым, но, возможно, это только я.

В любом случае, как и в предыдущем пункте, пожалуйста, не стесняйтесь предлагать что-нибудь, что может придумать, я буду очень признателен за любые отзывы, которые вы можете дать мне.

4

Решение

У меня тоже есть сайт электронной коммерции. Вот мой совет о том, как мне реализовать упомянутые вами функции. Надеюсь, поможет.

  • категории

Я организую их в плоскую структуру, в вашем случае это будет:

    {_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, Это не вступает в противоречие с наследованием, упомянутым выше, поскольку с какого-то уровня подкатегории начинают использовать одни и те же параметры. Это полностью связано с тем, как вы организуете свою структуру категорий. И если вы захотите изменить структуру категории или переместить продукты какое-то время, это будет болезненно. Так что будьте осторожны при определении ваших категорий.

Это все, что приходит мне в голову. Боюсь, я не являюсь носителем английского языка, поэтому вам может быть трудно понять какую-то часть моего ответа. Не стесняйтесь, дайте мне знать.

5

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]