Доброго времени суток.
Суть вопроса такова: интернет-магазин одежды.
Структура: есть товары разных цветов, у каждого цвета - свой размер.
Сейчас я реализую таким способом:
Виртуальный товар 1 (общий) - Виртуальные товары 2 (по цветам) - Реальные товары (по размерам для каждого цвета).
Проблема в том, что идет слишком много запросов в БД, время ожидания для юзера слишком велико.
Также, есть поиск на сайте и фильтрация, которую осуществляю через haystack+elasticsearch. С такой структурой, как сейчас, довольно-таки проблематично "запихать" всю информацию о товаре в индекс. Как следствие, вновь будут запросы к БД.
Подскажите, кто решал подобную проблему? На какой структуре Вы остановились?
спасибо
sim3x: структура типична. модель Product, с обычными свойствами для товара.
В индексе у меня конечные товары (реальные, с размерами товара), а выводить я должен виртуальный товар. Поэтому, после того, как я отфильтровал, необходимо "выдрать" родителей для товара и вывести их в шаблон.
Через Debug ToolBar увидел, что для 50 товаров идет порядка 1800 запросов (ищет родителя для товара)
спасибо.
class Product(MPTTModel,SeoModel):
color = models.CharField('Цвет',blank=True,null=True,max_length=200)
size = models.CharField('Размер',blank=True,null=True,max_length=200)
stock_amount = models.FloatField(_(u"Stock amount"), default=0)
sub_type = models.PositiveSmallIntegerField(_(u"Subtype"), choices=PRODUCT_TYPE_CHOICES, default=PRODUCT_WITH_VARIANTS)
parent = models.ForeignKey("self", blank=True, null=True, verbose_name=u'Родитель', related_name="variants")
# для связывания товара с категориями и свойствами
categories = models.ManyToManyField("Category", blank=True)
Соответственно, у первого виртуального - parent пустой. Далее, мы указываем parent у потомка (виртуальный (общий)-виртуальные товары по цветам - реальные товары с размерами)
parent = models.ForeignKey("self"
ТЗ для меня не ясно, но я не вижу причин, когда у одного товара будет больше одного уровня вложенности c SKU
Те сделать отдельную модель, которая будет Товаром и у которой будет несколько вариантов в виде SKU
sim3x: categories - для связи с категориями. То есть чтобы получить товары для нужной категории, вызываю как product_set....
Проблема в том, что мне всегда необходимо делать запрос (get_root(), например), чтобы дойти до конкретного родителя в дереве, а хотелось бы, чтоб товар полностью находился в индексе. Тогда при фильтрации не будет никаких дополнительных запросов к БД.
sim3x: да, товар же может быть в разных категориях (одежда-джинсы-классические джинсы).
вообще, приходит xls файл, с товарами по типу "Размер 55, цвет Красный, артикул 444444, название).
Далее, для удобства редактирования в админке, так и для вывода карточки в категории, я создаю 2 виртуальных товара. Первый - содержит в себе все цвета, а второй - все размеры для данного цвета.
То есть мне необходимо отобразить сразу всю инфу в одной карточке: сколько есть цветов, сколько размеров для каждого цвета.
sim3x: Правильно ли я понимаю, что будет основных три модели: категория, товар, вариантТовара
class Category(MpttModel):
name = models.CharField('name')
.....
class Product(models.Model):
category = models.ForeignKey(Category)
brend
class ProductVariant(models.Model):
sku
product = models.ForeignKey(Product)
color
size
price
.....
То есть "дерево", как таковое через MPTT в Product и не нужна вовсе?
спасибо
sim3x: да, в категории у меня как раз и используется MPTT для показа "дерева".
Обычно, были типичные магазины, в которых только: категория-товар (например, это для магазина электроники подходит).
для магазина одежды структура уже меняется: необходимо "объединять" товары по их цветам.
Я представляю себе это так: "коробка". В ней товары, допустим 9 джинс трех цветов: желтый, синий, красный.
То есть первая абстракция: "коробка", на которой обычно пишут всю инфу о товарах (сколько цветов, сколько размеров)
Вторая: цвета. В нашем случае их три: желтый, синий, красный.
Ну и третья - уже по размерам для цвета.
Да, так реально можно запутаться, если тупо идти по дереву, куда проще создавать отдельные модели)
для магазина одежды структура уже меняется: необходимо "объединять" товары по их цветам.
можно сделать модель цветов и выбирать цвет товара оттуда
Я представляю себе это так: "коробка". В ней товары, допустим 9 джинс трех цветов: желтый, синий, красный.
То есть первая абстракция: "коробка", на которой обычно пишут всю инфу о товарах (сколько цветов, сколько размеров)
Вторая: цвета. В нашем случае их три: желтый, синий, красный.
Ну и третья - уже по размерам для цвета
У нас БД должна быть в 3нф
И всю информацию, которая в физическом мире обязана быть избыточно написана на "коробке" в партии товара, которая принадлежит одной коллекции, мы можем взять из БД
Когда запросов станет много и кеширование перестанет помогать, тогда можно будет внести в Коллекцию,
поле м2м со списком цветов
поле м2м списком размеров
поле м2м со списком размеров и тд
sim3x: Структуру понял)
Получается, что для фильтрации товаров по свойствам и для поиска, через haystack+elasticsearch, в индекс пойдут "ВариантТовара", а вот уже на "выдаче", мы должны пройтись по всем выданным haystack товарам, и "вытащить" из них "Товар". Верно?
sim3x: на сайте все равно нужен и поиск, и фильтрация. Дабы БД каждый раз не дергать, можно запихать все свойства для фильтрации (цвет, размер, бренд, категория, цена) в индекс. Тогда, думаю, быстродействие увеличится.
Да, именно коллекцию. Необходимо в каталоге, показать всю инфу о товаре: сколько есть цветов, сколько размеров у конкретного цвета и фотографии (прикрепил фото)
sim3x: Забыл еще такой момент.
Получается, что фотографии будут "дублироваться" у товаров с одинаковым цветом?
Например, красные джинсы - фото одинаково для размеров 41,42,43 и так далее...
Аналогично, для всех остальных цветов.
sim3x: вариантов то решения не так и много.
да, я имею ввиду, что один цвет может иметь несколько фоток, и размеры одного цвета также имеют эти же фотки.
Поправьте, пожалуйста, если я не правильно рассуждаю.
class ProductImage(TimeStampedPositionModel):
product = models. ManyToManyField(ProductVariant)
image = ImageField("изображение", upload_to="uploads/products")
sim3x: Тогда мы вновь возвращаемся к вопросу о повторении)
допустим, заполняем реальный товар (с размером).
41 размер джинс красных: заполнили всю инфу, перешли к фото. Фото в виде inline - выбираем их и сохраняем.
Переходим к 42 размеру джинс красных: заполнили инфу. Получается, фото вновь выбираем теже?)
немного запутался, если честно)
да, я это и имею ввиду:
джинсы 41, 42, 43 и так далее размеров, красные (например), должны иметь одни и теже фотографии.
А в админке, выходит, что мы должны выбирать для каждого размера один и тот же набор фоток для данного цвета.
sim3x: я думаю, что для случая "Фото одинаковы в рамках одного цвета", необходимо сделать так:
ФотоТовара
путь
товар = ForeignKey(Товар)
цвет
То есть фотографии "цеплять" не к вариантам, а к виртуального товару "Товар".
И в модели ТоварВариант написать метод по типу get_images, который будет "вытаскивать" фотки по цвету от своего родителя (виртуального товара). Тем самым, не будет дублей, и фотки будут, так сказать, как "на ладони"))
sim3x: сейчас фотки связываются с товарами с помощью штрихкода: в названии фото запихивается штрихкод (45423423423.jpg, 45423423423_1.jpg, 45423423423_2.jpg).
То есть, я думаю, можно при добавлении фото к их виртуальному товару, сохранять этот штрихкод в отдельном поле.
А у ТоварВариант, в его @property методе get_images(), "вытаскивать" их по штрихкоду. При этом, цвет товара будет только в ТоварВариант).
sim3x: на самом деле, она и так там есть, как отдельное поле "Штрихкод".
Я про то, что каким образом "вытаскивать" (присваивать) фото товарам одного цвета, не делая дублей и имея эти фотки всегда как на "ладони" - чтоб, например, можно было их сортировать и менять.
Таки да, вот, например, как можно реализовать метод get_images:
sim3x: хм ,хм, таки да)
но, если делать m2m, то ТоварФото надо еще "цеплять" к виртуальному товару.
То есть в админке будет вид:
виртуальный товар и его свойства
- фотографии (m2m)
- список товаровВариантов
верно?
получается, мы будем иметь некий набор постоянных фоток, но, уже присваивать мы их сможем любому количеству товаров? Выходит, все равно, для одного цвета - один и тот же набор фотографий. Наверное, это и не так критично, ну и с такой схемой "механизм привязки фоток" более открыт.
sim3x: Немного изменил схему.
Необходимо в шаблоне группировать варианты по цветам, и выводить размеры для первого цвета.
(на фото - это цвета справа). А слева - это размеры в рамках одного цвета.
Сделал как: добавил модель Color:
Color:
name = название цвета (желтый, синий, красный)
image = превьюшка для цвета
product = FK(Product) - виртуальный товар, то есть общий
variants = M2m(ProductVariant) - у одного цвета может быть несколько вариантов
Ну а фотки, и всю прочую инфу - храню уже в конкретном товаре.
Фото - как m2m для варианта.
Пока непонятно, насколько эта схема будет производительна (дабы не делать дополнительные запросы, а выдать все разом). (пока, вытаскиваю первоначально всю инфу для виртуального товара через prefetch_related("colors").all()
sim3x: Просто я уже все варианты перелопатил)
В карточку товара (каталог), при загрузке выводится:
1. Все цвета для данной группы товаров (объединяются по артикулу) - на картинке это справа кружочки
2. Фотки первого цвета (допустим, красного)
3. Размеры первого цвета (допустим, 33,34,35, 36, 37).
На выходе получаем картинку (вложил).
При клике на цвет - аяксом меняем фотки на фотографии нажатого цвета + меняем размеры на те, который содержит в себе данный цвет.
Получается (если грубо описать), мы имеем:
Общий виртуальный товар (содержит все) - далее идут "Цвета" - и уже от "цветов" пошли реальные товары (с размерами).
То есть параметр "цвет", видимо, надо выносить либо в отдельную модель и присоединять к виртуальному товару, либо как-то группировать на выходе (в шаблоне). то есть мы же можем иметь 3 красных джинс, 5 синих, 2 белых, а в "карточке" каталога мы должны показать только: "красный", "синий", "белый".
Важно сохранить быстродействие. select_related, prefetch_related использую.
Надо все же определиться - у нас дофига фоток на все размеры и цвета или их нехватка, которая привела к использованию одинаковых фоток для разных ВариантовТовара
ТипТовара
название = (джинса, футболка, ...)
Коллекция
марка
Товар
коллекция = FK(Коллекция)
тип_товара = FK(ТипТовара)
ФотоТовара
фото = imageField
ВариантТовара
артикул
товар = FK(Товар)
фотки = m2m (фотоТовара)
цвет = м2м(Цвет)
Цвет:
ргб = CharField() # "#000000"
название
sim3x: вообще, мы можем присваивать каждому реальному товару (который с размером) свою партию, но, тогда получится просто дублирование, так как в рамках одного цвета - фотографии одинаковы.
В каталоге, как я понимаю, нам все равно нужен Товар. Но, этот виртуальный товар должен "знать", сколько у него цветов товара, и сколько размеров в каждом цвете. Ну, а показывать фото можно тупо самого первого в каждом цвете.
Вот я и думаю, если фотки пихать в цвета? Тогда получается схема:
- вирт.товар
- цвет
- размер
- фотографии.
Или на примере:
-Джинсы KK
-синие (здесь же фотки синих)
- 41 размер
- 42 размер
-красные (и фото)
- 43 размер
-зеленые (и фото)
- 41 размер
- 42 размер
sim3x:
И после сгруппировать?)
Я думал, что ВариантТовар содержит в себе только один размер.
То есть:
ВариантТовар красный 41 размер
ВариантТовар красный 42 размер
ВариантТовар синий 43 размер
Таки полностью достаточно, грубя говоря, двух основных моделей Товар и ТоварВариант? И сопутствующих с ними Фото, Категория...?
в шаблоне:
{% for virtual in products %}
{% with virtual.variants.all|first as firstProduct %}
#выводим фотки товара в цикле
#выводим основную инфу товара
? как выводить цвета? (или же просто брать первый товар из любого цвета?)
{% endwith %}
{% endfor %}
Не будет ли слишком много запросов? Ведь, насколько я понял, мы выводим (собираем) только виртуальные товары из данной категории, а "реальные" уже "подтаскиваем" с помощью запросов.
КатегорияТовара (MPTT)
название = (джинса, футболка, ...)
Бренд
Название бренда
Товар
категория = m2m(КатегорияТовара) (один товар может находиться в несколькоих категориях - по дереву)
бренд = FK(Бренд)
ФотоТовара
фото = imageField
Цвет:
imagePreview = imageField (берем "кусочек" фотки как цвет. При наведении - выводим title, например, красный)
название
ВариантТовара
артикул
цена
размер
товар = FK(Товар,related_name="variants")
фотки = m2m (фотоТовара)
цвет = FK(Цвет) (цвет может быть только один у варианта)
views.py:
(берем slug категории)
category = КатегорияТовара.objects.get(slug=slug)
vProducts = Product.objects.filter(category=category).prefetch_related("variants","variants__color","variants__images")
рендер в шаблон vProducts - все "виртуальные товары" для данной категории (со всеми его вариантами). Одновременно, варианты тащат за собой цвета и фотки в одном запросе.
В шаблоне:
- в цикле проходим по всем "виртуальным товарам" (имеем пустую "карточку" - заготовку, контейнер)
- через regroup делаем нужный нам вид (группировка по цветам)
Вариант через regroup:
1. Группируем в шаблоне по цвету
2. Выводим список grouper - это наши цвета (синий, зеленый, красный)
3. Выводим слева список размеров для первого цвета (допустим, синий: 41,42,45).
4. Фотки - выводим фотографии для первого варианта из цвета.
5. Ну и при смене цвета - аяксом меняем: фотографии (новый набор из нажатого цвета), и размеры - это уже отдельная логика, но, уже не такая мудреная, так как данные манипуляции можно сделать во view и кинуть их через json. Набор цветов мы формируем всего один раз - при начально инициализации, так как данный набор не меняется. По сути, именно этот набор и меняем весь вид карточки в каталоге (от цвета зависит и набор фоток, и набор размеров).
{% regroup product.variants.all by color as colors %}
<p>Цвета</p>
{% for color in colors %}
{{ color.grouper }}
{% endfor %}
<p>Размеры первого цвета</p>
{% with colors|first as firstElements %}
{% for variant in firstElements.list %}
<b>{{ variant.size }}</b>
{% endfor %}
{% endwith %}
Протестировал на одном товаре - пока все верно выводит, и запросов всего 3 на каждую карточку.
Единственное, при первом старте будут дополнительные запросы к sorl-thumbnail, так как превью еще не созданы и их нет в кеше. После первого старта, sorl-thumbnail будет тащить фотки с кеша, что также уменьшит количество обращений к БД.
Уточнение - цвета и азмеры нужно свзяать между собой.
Пример: выбрали цвет = показало доступные размеры
Да/нет?
Да. В каталоге, когда идет список "виртуальных" товаров, именно так и происходит: выбираем цвет - показ размеров для данного цвета. Но, если можно тупо группировкой это сделать - то тоже рабочий вариант (как я описал выше).
Пример: (начальное значение): показ "красного" цвета - выводим только размеры для красного (41, 42).
Жмем на "зеленый" - показ размеров только для зеленого набора (43, 45).
причем, цвет - кликабелен (ссылка), а вот размеры - чисто информационные данные.
Зачем цвет делать куском фотки, если он по моей задумке должен быть общий для многих ВариантовТоваров?
так будет более информативно. В "кружочек" мы сможем запихать "кусок ткани", например, а при наведении мыши юзер увидит тултип - "Красный" (например).
Кратко подытожу:
1. Приходят только товары, которые содержат в себе размер.
Вот пример, что приходит в файле:
2. Понятно, что было бы проще, если б мы просто показывали все эти товары, как индивидуальные карточки. Но, это не совсем корректно). Именно поэтому и делается "группировка" товаров по их артикулу (общий товар) и по цветам.
3. Необходимо объединять товары по цветам
4. Каждый набор цветов (например, красный) должен содержать в себе набор размеров для данного цвета
5. Приходят фотографии, которые мы должны привязать по штрихкоду. Фотографии для товара одинаковы в рамках одного цвета.
6. Необходимо делать как можно меньше запросов к БД, так как при большом количестве запросов, время ожидания для юзера будет слишком большим, и он тупо уйдет с магазина))
sim3x: Протестировал с группировкой цветов в шаблоне (через regroup). В принципе, работает довольно-таки быстро, и логика более прозрачная. Мы не задумываемся над тем, как группировать по цветам и их размерам в цвете во вьюхе, а передаем всю эту логику "клиентской" части. Во вьюхе логика проста до безумия - берем только "виртуальные товары" из данной категории, и все)
Насколько это практично - точно не знаю, но, данное решение тоже имеет место).
mr_drinkens89:
возникли теперь проблемы с фильтрами)
Я формирую фильтры слева (бренд, цвет, размер, цена).
цвет и бренд - хранятся как FK, а размер и цены - это уже обычное текстовое поле.
Логика такая:
1. Собриаем все "чекеры", и в урле тогда будет примерно такое:
color=зеленый,синий,красный&size= 33,35,49&brend=adidas.
2. Кидаем все это дело во вьюху
3. Во вьюхе собираем, и делаем запросы к ТоварВариант по типу: variants = variants.filter(size__in=sizes)
4. Ну и на выходе берем из варианта его виртуальный товар и собираем все это дело в один массив:
vProducts = []
for product in variants:
vProducts.append(product.product)
В итоге, страница сейчас "висит" еще больше, чем это было у меня с JSONField)))
Быть может, все же, лучшим решением будет - фасетный поиск?
sim3x, добрый день) вновь задался вопросом со структурой и верностью его создания в своем интернет-магазине.
По поводу подвариантов товаров - разобрался. Вроде бы все ок работает, но, возникают сложности при добавлении функционала или расширении.
По структуре, в магазе следующий вид: "мужчинам", "женщинам". Далее, идут главные категории "Обувь, одежда", ну и сабкатегории (джинсы, брюки).
Такой вопрос: делать ли мне отдельно модель "коллекции" ("мужчинам/женщинам"), потом модель "ПодТипы ("Одежда, Обувь") и в конце - категории ("Джинсы, брюки"). Или же можно оставить все в одной модели Category?(MPTT)
Каждый товар, если он находится "в последней" категории - может находиться и в категории выше (То есть если джинсы "Гуччи" находятся в джинсах, то они также есть и в "Верхней одежде" и в "Мужчинах").
Помнится, был разговор по поводу тегов, что можно добавить поле "тег" в товар, и пихать туда категории.
Какая схема более рациональна и проста?
Сейчас юзаю MPTT (чтобы дерево нарисовать), ну и вид товара такой (кусок):
class Category(MPTTModel, SeoModel):
name = models.CharField("Название категории", max_length=250)
slug = AutoSlugField("Slug", unique=True, populate_from='name', always_update=False, max_length=255, editable=True)
parent = models.ForeignKey("self", verbose_name="Родительская категория", blank=True, null=True
description = MarkdownxField("Описание", blank=True)
display = models.BooleanField("Показывать", default=True)
class Product(SeoModel):
sku = models.CharField('Артикул', max_length=250, help_text='Объединияет между собой все варианты воедино')
color = models.ForeignKey(Color, verbose_name='Оригинальный цвет (из файла резерва)', blank=True, null=True, on_delete=models.SET_NULL)
name = models.CharField('Название', blank=True, max_length=350)
slug = AutoSlugField("Уникальная ссылка", slugify=custom_slugify, unique=True, populate_from='name', editable=True)
category = models.ManyToManyField(Category,verbose_name='Категория',blank=True,null=True,related_name='my_category')
brend = models.ForeignKey(Brend, verbose_name='Бренд',blank=True,null=True, on_delete=models.SET_NULL)
sim3x, так руководство решило. У джинс родитель "Одежда". Не совсем логично, но, ничего не поделать.
Просто я думал сперва, что можно обойтись лишь FK к категории. Но, товар может находиться в любой категории выше по дереву. Соответственно, тут только m2m к категории, насколько я понимаю.
