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

Question

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

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

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

Answer 1

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

• Категория

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

{_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, value -> [все подкатегории]. Обычно ваши категории не будут меняться часто, и у вас не будет много категорий. Таким образом, все будет хорошо.

• Метки/Опции

Прежде всего, я думаю, что есть что-то не так с вашей категории. Women fashion - это нечто общее, вы должны поместить свой продукт в нечто более конкретное, и параметры должны быть там тоже. Например, может быть категория coat, которая имеет size & color, кроме women fashion. Хотя может быть color вариант в women fashion, потому что это общая характеристика для всех подкатегорий.
Если вы думаете об этом, почему все подкатегории организованы в одну родительскую категорию? потому что у них есть что-то общее. Эта общая часть должна быть общими вариантами родительской категории. то есть должно быть наследование между всеми родительскими категориями и подкатегориями. Например:

женщины моды: цвета
| -coat: размер
| -Sun очки: форма

Тогда coat бы, наконец, имеет 2 варианта color & size. sun glassescolor & 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. Tricky часть Unit что, например

1GB = 1024MB = 1024*1024B 

Итак, когда вы получите жесткий диск 1 Гб и 1 Тб, вы можете выполнить преобразование до фильтрации продуктов. Это не в тему, я вернусь к вашему вопросу.

Обратите внимание, что хотя варианты разных категорий имеют одинаковое имя. Они вряд ли совпадают. Material от Coat и Furniture - это две разные вещи. Поэтому я склонен определять разные варианты для разных категорий. Таким образом, возможно, color для toys и color для women fashion. Это не противоречит упомянутому выше наследованию, поскольку с некоторого уровня подкатегории начинают использовать одни и те же параметры. Это полностью связано с тем, как вы упорядочиваете свою структуру категорий. И если вы хотите изменить структуру категории или переместить продукты некоторое время, это будет болезненно. Поэтому будьте осторожны, когда вы определяете свои категории.

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