пожалуй)
спасибо

Это уж от вашего проекта зависит. В широком и функциональном смысле, — нужно одновременно и проще, и сложнее:
В схожей по логике системе предусматривали возможность заведения любого типа характеристик для любой категории, а типы соответствовали традиционным типам полей html-формы.
То есть были:

1. числа
2. строки
3. текстовые
4. чекбоксы
5. селекты
6. мультиселекты
7(!) лейбл

Соответственно, структура получилась такая:

rubrics

rubrics_rows - характеристики
id parent_id row_sort rubric_id row_name name type required ...

В пояснении нуждается только parent_id — характеристики у меня могут иметь свое дерево (визуализация конечных html-форм с legend для нескольких полей и вообще любая их логическая группировка и сортировка)

rows - значения характеристик товаров
id id_row id_item rows_val

rubrics_rows_select - варианты значений селектов и мультиселектов.
id row_id value

upd. Не помню по какой причине решил заводить отдельную таблицу (видимо, после тестов с боевыми данными), но, очевидно, вполне можно ограничиться добавлением поля value для списков в таблицу характеристик rubrics_rows и будет минус один join

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

upd. ещё был лейбл, который не имел никакого значения, а просто заводился для категории (заполнялись только поля name и description) и был родителем для других групп её характеристик. Опять же это делалось в целях адекватной визуализации дополнительных полей категории товара или что у вас там, благодаря связям родитель-дочки. Извините, но красивые схемы в wb формировать лень : вроде и так все понятно.

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

по моему прежде нужно определится с терминологией

тип атрибута -по сути тип данных ( число строка список...)
сам атрибут - вес, цвет, интерфейс
значения атрибутов - 2кг, белый, wifi

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

Разумеется нет совершенно никакой привязки к html, это было упомянуто для лучшего понимания разработанной структуры бд. Реальные типы полей там varchar для всех полей кроме text, int и tinyint/bool для чекбокса, а уж визуализировать их хоть в html хоть во что угодно.

То что вы указали полностью соответствует структуре таблицы значений атрибутов - rows.
Соответственно, для "списков" (может быть заведен атрибут с ограниченным списком значений для выбора) пишется одно значение, для "множественного списка" — все выбранные пользователем значения через любой разделитель.
Для логического типа атрибута при добавлении товара либо ничего не записываем (не выбрано), либо записываем имя атрибута, либо true/false, 1/0 — что удобнее.
Все это прекрасно скармливается сфинксу для адекватного поиска по атрибутам.

Разумеется не нужны: для того и делали единую таблицу значений без гемороя, как у ТС. Речь шла о выборке для визуализации, например, страницы товара или формы добавления товара.


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

К примеру:

2 варианта поиска:

а. простой
б. расширенный

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

Учитывая, что атрибутов по которым реально будут искать будет примерно 3-10 для каждой категории (исходил из того, что может быть до 20). И встает вопрос когда именно правильнее извлекать значения этих атрибутов?
То есть пользователь указал параметры быстрого поиска, выбрал категорию и потом перешел в расширенный поиск. Задача построить ему форму со всеми атрибутами категории участвующими в поиске.
Вот для последнего проекта прикинул, что в реально таких атрибутов будет порядка 100. Посему от аякса решил отказаться и просто держу в кэше лаконичный json со всеми этими атрибутами для всех категорий (он на самом деле не большой), что позволяет без дополнительных запросов показывать юзеру расширенную форму поиска.
Как вы поступили, если была задача делать поиск по любым атрибутам, caballero?

что значит "по любым"
какие есть для данной категории для таких и строится форма расширенного фильтра

По любым атрибутам в рамках конкретной категории (в случае с конкретным последним проектом администратор мог выбрать те атрибуты по которым идет поиск в рамках конкретной категории чтобы не держать лишние пухлые поисковые индексы в системе).

Суть вопроса в том, как вы их получали для поисковой формы: выбирали по запросу аяксом по переходу в расширенный поиск в рамках категории, или держали в кеше изначально, или и то и другое. Если держали в кеше, то отдавали-ли вместе с каждой страницей в виде js-объекта или отдавали кэш по аякс-запросу.
Потому что юзер может кликнуть по одной катеогрии, кликнуть по другой и т.д.

просто выбираю из таблицы - атрибуты привязаны к категории
(Добавление)
если юзер кликнул по категории все равно перерисовывается страница

Да я понимаю что из таблицы, откуда же ещё. Я веду речь о моменте выборки. Как я понял, вы делаете выборку в момент выбора пользователем категории, то есть в живую тянете из таблицы имена атрибутов и jsoном шлете обратно клиенту чтобы визуализировать форму.

Конечно это субъективно для проекта, но в моем случае это было не торт. Ибо фактически без ограничения по аяксу делается селект с джоинами дополнительных атрибутов катеогрии участвующих в поиске. В моем случае их было от 2 до 20 для каждой. И что вы тянули их каждый раз из таблицы при клике пользователя на разные категории?

У себя решил так:
Проект весьма нагруженный, пользователям играться с новой формой понравилось и стали постоянно дергать поиски по разным категориям. Посему сначала сделал единый кэш с jsonом всех атрибутов учавствующих в поиске всех категорий, который отдавал по ajax при клике на категорию в поиске. Затем, видя как распухает количество категорий и атрибутов, стал отдавать из кэша json только по запрошенной категории. Если юзер сначала кликал по 1 категории — ему отдавался кеш атрибутов, потом по другой — ему отдавался кэш атрибутов другой категории. если кликал по той, что уже выбиралась ранее — использовался принятый ранее json этой категории (сейчас как раз прикручиваю для этого использование локального хранилища в браузере).

Конечно, тут все упирается в задачи проекта. В конкретном проекте атрибутов для поиска было много, но добавлялись они не часто, потому была возможность использовать кэши.
Скоро попросят делать добавление атрибутов в поиск пользователями сайта с последующим обновлением поисковых индексов сфинкса с обновлением кэшей .

у меня нет поиска по категориям
юзер выбирает нужную категорию

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

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


.

caballero, в среднем в России крупными сайтами занимаются команды до 10 человек программистов (яндекс не в счет). Насчет интернет магазинов - это не домашние странички, а готовые движки, например ShopScript ... приходится с ним сейчас работать, не так он отвратно написан, как я сначала думал

тема вообще то о велосипедах

мало ли кто там что написал
тем более програмеров может быть 10 а комюнити 10000