#база_данных #sql #mysql
Доброго дня всем! Имеется набор товаров. У каждого товара есть некоторые свойства. Свойства могут быть - групповыми(длина,ширина,высота), одиночными (вес, цвет) - списковыми(тот же цвет: есть несколько четко заданных вариантов расцветки), строковыми(надпись сбоку, например), числовыми (тот же вес). - общими для всей группы товаров(длина, ширина, высота), уникальными для конкретного товара(какая-то особенность) У некоторых числовых свойств есть единицы измерения, например, метр, миллиметр, кг и так далее. У этих единиц измерения есть возможные написания, в зависимости от числительного 1 минута, 2 минуты, 5 минут, а так же сокращенное написание: мин. В итоге, у меня получается довольно громоздкая система таблиц: catalog_groups id, parent_id, path, title catalog_items id, group_id, title catalog_group_parameters id, id_group, type, value catalog_parameters parameter_id, item_id, value catalog_list list_id, id, value catalog... ну и так далее, все равно никто читать не будет. Проблемы, которые не удалось решить: Если есть общие величины, вроде высоты, которые распространяются на все-все, как их объединить в одну? При этом, скажем, цвет - это разные параметры, так как списки цветов разные для групп. Получается, иногда в значении value для параметра у меня именно значение, а иногда - идентификатор списка. В общем, как умные дяди и тети это организовывают?
Ответы
Ответ 1
Вообще таблица видов свойств должна быть одна. На все группы. Т.е. цвет и высота - это два свойства, а не 2*количество групп. При этом у товаров будут те свойства, которые есть (пусть даже набор свойств у разных товаров одной группы будет отличаться). Далее для каждой группы должна быть развязочная таблица, что в этой группе есть такие-то свойства (т.е. group_id, parameter_id), по которым можно фильтровать. При этом значения для фильтра берутся distinct'ом (для диапазонов соответственно min/max) по значениям этого свойства для товаров в данной группе, т.е. список значений хранить не нужно, соответственно и разделять свойство "цвет" для разных групп нет смысла, лишние цвета в фильтр не попадут. Тогда проблемы с идентификаторами списков возникнуть не должно... N.B. Свойства делятся на: булевы (в плане выбора виджета - чекбокс, понятно что можно и радио и селект сделать на два элемента). числовые или дата (сравнение больше, меньше, диапазон) строковые (совпадение по строке, по подстроке) лукап (одно значение из списка возможных значений) множественный лукап (когда можно выбрать несколько значений: красные или синие) более сложные варианты типа по подстроке множественного лукапа (синие: "темно-синие", "светло-синие", "синие в белую полоску") или поиск по древовидному справочнике - в детях. зависит от причудливости справочников. Ну и для каждого варианта строится свой виджет в фильтре. ЗЫ Надеюсь правильно понял проблему.Ответ 2
Попробую накидать примерную структуру. Что-то подобное делал, "но есть нюанс". Таблицы: 1. fields [ field_id, name, type(group/bool/int/list/color), <...>, is_multiple(0/1)] 2. values [ product_id, field_id, value ] 3. groups [ group_id, cat_id, name, <...> ] 4. fields_link [ field_id, link_id, link_to(группа, поле-группа, товар)] Соотв-но наши действия: 1. Создание категории 2. Создание группы полей для категории 2.1. При создании подкатегории клонируем группу с прилинкованными полями 2.2. Добавление в эту группу существующих полей и/или создание новых 2.2.1 для групповых свойств создаем группу-поле и линкуем их туда 3. Создание товара 3.1. Заполнение полей 3.2. Создание уникальных (при таком раскладе, если поле создано где-то еще, можно привязать из общего списка) 4. Вывод Для вывода получаем список полей (вроде должно быть прозрачно, линки по группа/категория, подгруппа/группа, поле/товар), следом получаем все значения (банальным SELECT * FROM values WHERE product_id={$product->id}, потом в скрипте дописываем полям значение, сортируем, добавляем окончания, форматируем etc). Множественные, кстати, учтены - их просто будет несколько в таблице values. Вопросы в каменты)
Комментариев нет:
Отправить комментарий