Для примера взят каталог товаров http://catalog.onliner.ru/
Здесь мы видим разбитые на категории товары. Если мы зайдем в категорию, например мобильных телефонов (http://catalog.onliner.ru/mobile/), то справа увидим панель поиска нужной модели телефона по определенным критериям. Собственно мой вопрос состоит в том, как реализовать подобную модель разделения товаров с последующей выборкой по необходимым кастомным признакам. Делать для каждого вида товаров (а у каждого вида товара свой набор признаков, по которым позже будет происходить поиск) отдельную таблицу мне не кажется разумным выходом из ситуации.

Какие еще есть предложения, кроме:
использовать отдельную таблицу критериев для товаров (связывается с товаром через parent_id) ?

так сделай общую таблицу для товаров, в которой создай чёткие поля общих широко распространённых признаков, как-то цена, габариты, вес, цвет, дата выпуска и т.д. а затем ряд полей с неопределёнными параметрами: param1, param2, param3. исходя из количества данных и типов параметров часть полей сделай int, часть varchar(n). остаётся добавить поле id_categor. и теперь при выборке просто указываем where id_categor=5 and ... далее список необходимых критериев именно для этого типа товаров

Никак не пойдет представленный вами вариант. Товары спичка и машина несомненно имеют некоторые общие критерии, но я заранее не знаю сколько всего критериев будет, так что дополнительные поля глупая затея.

вы знаете лучше?

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

В начале топика писал, как будет. Нужен будет поиск в каждой категории товара по определенным критериям.

Добавлено через 3 минуты и 44 секунды
Просто у одного товара критериев может быть 5, а у другого 55. И вы думаете, что проектирование таблицы товаров с большим количеством доп полей (большинство из которых будет пустовать) является разумным решением?

console, можно отдельно таблицу аттрибутов товаров: id_товара, id_аттрибута, значение. универсально и гибко. и громоздко. потому как поля бывают с произвольным значением(масса, к примеру), и со значением-жестко заданным списком("формфактор процессора"), и просто признак есть/нет(который удобнее отображать в виде чекбокса). значит, придется описывать эту логику в доптаблице "аттрибуты". и при формировании страницы усиленно join'ить таблицы друг с другом.
кроме того, на отдельное поле в одной таблице можно поставить индекс. в случае же использования доптаблицы индекс есть смысл ставить только на пару "id_аттрибута + значение", что не лучшим образом скажется на производительности.
с другой стороны, можно сделать кеш сгенерированных страниц с описанием(чтоб каждый раз заново не генерировать), кеш результатов поиска(очевидно, что по одним признакам ищут чаще, чем по другим) и произвести некоторую денормализацию таблицы(к примеру, значения самых частоискаемых аттрибутов вынести в дополнительное текстовое поле с перечислением значений через запятую и искать в первую очередь по этому полю). 

Skyboy, спасибо за советы... будем думать