Как правильно организовать фильтры поиска по товрам ?
Есть задача реализовать фильтр поиска по товарам. Есть идея и сразу пачка споров по этому поводу.
Исходя из ТЗ идея и реализация примерно такая:
Таблица категорий (бытовая техника, компьютеры, еда и тп.).
Таблица свойств (цвет, объем, упаковка, производитель и тп.)
Таблица значений базовых свойств (красный, зеленый, 1 литр, самсунг и тп.)
Таблица значений персональных свойств (например дата срока годности конкретного товара)
Таблица связь категория-свойство
Таблица связь свойства-значения
Собственно мы получаем много таблиц, и при этом споры идут будет ли такая архитектура быстро работать ?
Особенно если есть задача поиска, когда человек к примеру вводит "Красный айфон", то нужно определить свойство по значению (в данном случае свойство цвет, значение красный) и показать товары исходя из данного цвета.
Хорошая структура с учётом нормализации БД, при правильных sql-запросах проблем не возникнет.
Если исходить из того, какие поисковые запросы Вы будет посылать, то тут не обойтись без полнтекствого поискового движка аля сфинкс, а он большую часть нагрузки возьмёт на себя за счёт своих индексов и т.д.
Вы так же может слить данные таблицы в одну, с помощь view, где объедените только те поля, что не посредственно участвуют в фильтре, тем самым избавить код от лишних джойнов и перенести это на плече БД
nepster09: Плохо не джойны, а быть дураком. Некоторые пользователи пхп еще не вышли из каменного века, и верят в тысячи разнообразных суеверий. "Джойны это плохо" - одно из них. Но особенно смешно здесь звучит фраза "перенести на плечи БД" - как будто до заворачивания во вью джойны находились на чьих-то еще. В целом же это очень плохой и бессмысленный ответ - просто набор утверждений разной степени достоверности, ничего общего с вопросом не имеющий.
nepster09: А я не говорил, что джойны это плохо! Где вы это прочли? Я всего лишь сказал, что из кода они перейдут на уровень БД, что позволит Вам написать код работающий непосредственно с конкретным view для фильтрации. А структуру БД потом можете менять, как душе будет угодно, при этом не затрагивая код, ну при условие того, что view и логика фильтрации меняться не будет!
nepster09: Вот, что я имел ввиду под своим ответом, вот такую структуру.
Она правда не включается в себе персональные атрибуты (срока годности конкретного товара), для примера подойдет.
Т.е в View вы агрегируете данные для фильтра, и по этому конкретному view уже ищите, с помощью сфинкса или самой базы. Из view Вам получить нужно только product_id, а далее по ним получается конкретные товары для отображение результатов поиска.
KorsaR-ZN большое спасибо, я Вас понял. Я там еще все взвесил, походу тут нужно использовать все это дело без связных таблиц, а что-то типа вью выносить в nosql. Тогда это будет производительнее. Но я еще точно не понял как.
Если отбросить все попытки объяснений (фантастически бессмысленных) из предыдущего ответа, и оставить только рекомендации, то придраться будет не к чему.
Описанная структура хорошо известна - она называется EAV. Непонятно, почему она названа многотабличной - такой подход как рах позволяет сильно экономить таблицы.
Про плюсы и минусы этой архитектуры можно почитать в интернете. Один из минусов - это невозможность использовать джойны, поскольку в EAV-модели не соблюдается реляционность: поля таблицы хранятся в виде значений в другой таблице. Но плюсы перевешивают.
Если очень сильно хочется сократить количество таблиц - стоит посмореть в сторону нереляционных БД - например Монгу, которая идеально подходит для хранения каталога товаров.
Для поиска в любом случае надо использовать сфинкс - он для этого предназначен, и прекрасно справится с запросом "красный айфон" без какой-либо специальной подготовки. Как следствие, в силу использования внешнего поиска, мы оказывается отвязаны от структуры таблиц - она может быть любой, и для поиска не имеет значения.
Простой
