перечисляемые типы хлопотно хранить и обрабатывать
громоздко получается
поэтому я их храню через запятую в строке

например диапазоны для мобильных телефонов
900,1800,1900

такой же список подмножество из перечимлоенных) будет для конкретного телефона
или одно значение если множественное не допускается (например диагональ екрана)


потом по этому списку генерятся чекеры в форме поиска
(для всех атрибутов из категории свои елементы ввода)
потом берется по самиту отчекереные значения и для каждого добавляется "and like" в запрос поиска
(Добавление)
а енумы не какят потому как предпочитаю делать переносимую структуру для любой БД

предпологаемые "проблемы" в будущем:
заказчику сто пудово захоца чтоб один и тот же товар находился в различных разделах
это конечно можно было бы вынести в фильтры, но для поисковиков куда выходней если это будет именно раздел позволяющий максимально конкретно описать(титл, ключевые, описание),определить товар
что существенно подымит в выдаче

а по сему, жесткая привязка товара к разделу бесполезна

не факт


при чем описание товара к разделам

сходных свойств
"большой ноутбук", "маленький ..."
"матовый ...", "глянцевый ..."
пипл ищет вот так, а значит и раздел для поисковика должен так выглядеть

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

примеры выглядят смешно (возможно) но именно на разделы с такими титлами поисковики и переходят

ну так задавай титлы какие хочешь
а для поиска по филтру - конкретные атрибуты

мухи отдельно котлеты отдельно

во во, вот именно так рассуждают все разработчики, а вот реалии жизни ....

при отображении раздела будут отображаться и товары дочерних
а для сопутствующих товаров типа расходные к принтерам будет таблица соединения разделов сам к себе
отдельно
это не проблема

LIME,

я бы предварительно к Вашей схеме попробовал построить SQL-запросы (выборки), которые Вам понадобится в будущем сделать.
Посмотрел бы , как быстро вся эта схема работает.

Иногда приходится делать очень сложные запросы.

у нас вместо двух ваших таблиц feature_value_char и feature_value_int одна таблица feature_good_relation в которой есть:
good_id
feature_id
value_int
value_string
value_boolean

это позволяет получить нам значение свойств одним запросом. В твоей же реализации тебе надо сначала сделать запрос к features что бы получить тип свойства и понять, из какой таблицы брать связь. У нас же идет джойн одной и той же таблицы и в запросе ифами выбирается то или иное поле.

caballero по поводу перечисления через разделитель как-то это не комильфо
что если одно значение совпадет с частью другого?
я бы и сюда влепил таблицу отдельно))
по индексу и выборка побыстрее чем по LIKE должна быть по идее

Contr спасибо за совет но тут все запросы как бы и так видны из схемы

еще вопрос
я в таблицах связей делаю оба поля первичным
есть ли смысл добавлять отдельный индекс для полей для выборки?
например в таблице связи характеристик с категориями возможно вообще лучше снять индекс с id характеристик
?
(Добавление)
совершенно нет
тип свойства это для отображения фильтра
тоесть это радио или селект и тд
выборка значений предполагается всегда из обеих таблиц юнионом по ключам товара и свойства
(Добавление)
оно вроде как побыстрее должно быть чем условие в джойне типа coalesc(или как там оно пишется забыл)) )...нет?
(Добавление)