|
Задавайте вопросы, мы ответим
Вы не зашли.
Добрый день!
Пишу скрипт интернет магазина. Необходимо реализовать стандартный для интернет магазина функционал – возможность поиска по характеристикам. Причем по каждой характеристике выбираются один или несколько заранее известных вариантов.
Например, сайдбар выглядит подобным образом: (Галочками пользователь выбирает какие товары он хочет видеть.)
Стоиомсть:
[--[]---------[]-----] (ползунок)
5000-50000
Бренд:
[ ] Sony
[v] Panasonic
[v] Samsung
[ ] LG
Диагональ:
[ ] 24 дюйма
[v] 32 дюйма
[v] 40 дюймов
[ ] 46 дюймов
Наличие HDMI:
[ ] нет
[v] 2 порта
[ ] 4 порта
У каждого товара можно забить произвольный состав характеристик, к тому же характеристики в каждой категории товара разные, поэтому привязать жестко характеристики к таблице товаров нельзя. Я сделал такую структуру БД:
product
id
name
description
price
category_id
char
id
product_id
char_name_id
char_value_id
char_name
id
name
char_value
id
char_name_id
value
category
id
name
И предполагаю использовать такой запрос для выборки по фильтрам: (где тильды будет соответствующий ID)
Неактивен
Вообще интернет-магазины (в том числе такие крутые как магента) пишутся с использованием парадигмы eav (entity-attribute-value), подумайте в этом направлении. В Вашем случае, думаю, она и нужна.
Неактивен
Что-то в основном негатив пишут про EAV. А по сути нормальных подробных статей (что это такое и с чем его едят) по EAV я не нашел. Магента вроде как сильно пожалела что использовала EAV и в новых версиях отказалась от её использования. Видел вопросы подобно моему, именно про хранение произвольных характеристик товара в интернет магазине — но что-то все сильно усложняют, и я не пойму что я делаю не так.
Неактивен
Да критиковать-то не мешки ворочать, негатив очень много про что пишут. В то же время именно для магазинов (то есть для возможности простым образом создавать новые аттрибуты ) не встречал, честно говоря, более гибкого решения. А что стала использовать магента вместо еав?
Почитайте шестую главу в "Программирование баз данных SQL. Типичные ошибки и их устранение", там описываются альтернативные методы.
Неактивен
alexbobrow написал:
Магента вроде как сильно пожалела что использовала EAV
Неудивительно. Насколько я понял, принцип, лежащий в основе EAV, идеален с точки зрения абстрактной логики подхода (неограниченная гибкость), но структура БД получается тяжелой - отдельная таблица с характеристиками со всеми вытекающими последствиями.
Альтернатива тут - делать под каждый реальный вид товара (читай - под товары с одинаковым набором характеристик) свою таблицу, а на уровне языка программирования - наследовать от абстрактного класса, где перечислены общие для всех товаров свойства.
(При таком подходе есть ограничение: весьма трудно организовать общий поиск между категориями товаров. Но поскольку категории разные, то такой поиск имеет мало смысла, например, на amazon.com не будешь искать штаны вперемежку с телефонами.)
Неактивен
LazY написал:
Альтернатива тут - делать под каждый реальный вид товара свою таблицу
Вот так все и пишут. Либо EAV, либо под каждый тип товара свою таблицу — вот я и не пойму что не так с тем способом который я описал? Вроде и не EAV и не отдельные таблицы, в то же время структура простая, запросы не такие уж сложные, должно работать все быстро.
Прошу оценить предложенный способ и поправить если что не так. Или объяснить почему, если вариант плохой. Спасибо.
Неактивен
То, что вы предлагаете и есть реализация EAV (в частично нормализованном виде). Возьмем таблицу char:
id
product_id
char_name_id
char_value_id
id в ней не нужно (с точки зрения запросов точно), поэтому его опустим. Оставшиеся три элемента product_id, char_name_id, char_value_id - это ровно entity, attribute, value. То, что используются только id - следствие нормализации БД, к концепции хранения это не имеет отношения.
Думаю, что много путаницы из-за использования штампов для обозначения базовых понятий (как в данном случае EAV для частного случая реляционной модели БД). Потом к аббревиатуре привязывается "хорошо" или "плохо", хотя речь всего лишь о некотором классе решений определенной задачи.
Неактивен
Всем спасибо за ответы. Отдельное rgbeast!
Неактивен
Вы пишете какой-то фильтр товаров для ЦМС или свою собственную ЦМС интернет-магазинов?
Неактивен
alexbobrow написал:
Что-то в основном негатив пишут про EAV. А по сути нормальных подробных статей (что это такое и с чем его едят) по EAV я не нашел. Магента вроде как сильно пожалела что использовала EAV и в новых версиях отказалась от её использования. Видел вопросы подобно моему, именно про хранение произвольных характеристик товара в интернет магазине — но что-то все сильно усложняют, и я не пойму что я делаю не так.
В магазине при большом ассортименте товаров могут быть тысячи характеристик товаров. Как их можно хранить по другому, кроме как EAV?
Неактивен
AFAIK магента в новых версиях перешла с еав на flat-tables, то есть у каждого товара своя табличка. Видать, тоже неспроста.
Неактивен
