Цель
Добавить к модели 5 полей, которые будут его характеристиками.
Типа: Цвет: красный, зеленый, синий.
Чтобы затем фильтровать объекты по данным характеристикам. Выбрал зеленый и вернул зеленые объекты.
Вариант 1:
В таблицу модели добавить поле colors. Затем создать еще одну таблицу Colors. Куда внести цвета. При сохранении объекта в модель записывать в таблицу в поле colors id цветов.
И таких 5 таблиц.
Вариант второй:
Также создать поле colors и записывать в него id. Но названия цветов с их ID хранить не в таблице, а в каком-нибудь php классе-репозитории в константах и получать их из файла.
И таких 5 файлов.
Какой вариант выбрать? Стоит ли создавать 5 таблиц с 2-4 записями, которые потом почти никогда не будут обновляться?
Если у модели поле color = enum, то можно в одной таблице, если set - тут без второй таблицы не обойтись.
А вообще пох. Это соцопрос, что ли? Блаженных подсчитываете?
Кирилл Несмеянов, если брать colors
то в мой пример-таблицу заносить colors? А в другую таблицу values уже значения - красный синий? Я правильно понимаю процесс?
Не забывай то, что EAV нужен тогда, когда планируется расширение списка характеристик. Т.е. помимо цветов потом появится вес, размер, скорость, цена и прочее. В противном случае смысла писать подобное не имеет, только усложнит всё.
Кирилл Несмеянов, я только хотел написать. Имеет ли смысл в моем случае. Тема интересная. В такой схеме можно получать множество значений одной характеристики. Не только синий цвет, а еще красный и зеленый. Т.е. чекбоксы можно отправлять одной кнопкой. Сейчас думаю как сделать в моем случае - то-ли таблицу, как я выше написал для характеристик и сделать 5 столбцов в модели для значений (ид сохранять), или в файле просто константами прописать. Вообще нормальная ли практика такие вещи константами прописывать? Я преград никаких не вижу, но интуитивно сомневаюсь)
Кирилл Несмеянов, характеристики если и будут расширяться, то незначительно. И то врядли) Но думаю все равно попробовать сделать EAV в качестве теста и обучения т.к. очень интересная идея. Вообще спасибо за идею я бы не додумался так сделать. А третью модель Entity называют?
Кирилл Несмеянов, составил схему
Attribute (id, name)
Value (id, name, attribute_id)
Entity (id, name, value_id)
Непонятно насчет Entity. В тесте 'MacBook Pro' передают текстом. Так и делается? Ищут по имени сущность? Насколько я знаю не рекомендуется сопоставлять по name, только id т.к. запросы по id быстрее
