Symfony каталог товаров с динамичной фильтрацией?

Question

[Кирилл Горелов]

Стоит задача сделать каталог на симфони. Сама по себе задача простецкая. Но есть задача, что бы управление фильтрами товаров было из админки.
К примеру появляется новая характеристика у товара, ее нужно сделать через админку, а не через миграции БД,
Я такое могу сделать, только если менять структуру БД вручную и на каждую характеристику прописывать условие к БД в запросе.

Может есть бандл какой или может можно как-то таблицу организовать так, что это все будет работать как нужно?
Каталог товаров будет маленький.

Comments

[BoShurik]

Вам нужна EAV

Answer 1

[Виктор Кожухарь]

Самое простое решение в данном случае - использовать в базе данных дополнительное поле с типом данных JSON, в котором и хранить объект с такими дополнительными характеристиками. Т.е. мы тут как бы совмещаем функционал нашей SQL базы данных с функционалом документных NoSQL баз.
И доктрина и сами современные SQL базы позволяют искать данные по JSON.

Более традиционный вариант - это создание двух таблиц. Первая таблица options_list будет содержать список самих характеристик. Поля могут быть, например:

id - код характеристики,
name - наименование характеристики

Во второй таблице options_values будут храниться уже сами значения характеристик.
И у неё будут поля:

id - код значения характеристики,
product_id - код товара из таблицы products (или как там у вас), для которого создается характеристика. FOREIGN KEY,
option_id - код самой характеристики из таблицы options_list. FOREIGN KEY,
value - значение характеристики 

Comments

[Кирилл Горелов]

Это как раз то о чем выше писали про EAV, правильно же?

[Виктор Кожухарь]

Кирилл Горелов, Ну, в принципе, да. Хотя я даже и не знал о существовании специального термина для описания такой структуры. Подобный принцип организации данных является, строго говоря, говнокодом, потому что, если у вас данные будут разных типов, то поле value не может полностью соответствовать типу данных вашей характеристики, и вам придётся как-то сериализовать эти данные в строку, чтобы хранить в базе. Однако, т.к. задача у вас - не создавать новых таблиц, то это чуть ли не единственное решение в традиционном SQL