Почитал и понравилась идея. http://martinfowler.com/eaaCatalog/singleTableInheritance.html
Смысл в том, что бы хранить свойства товаров в полях (классы у нас будут виртуальные): id , свойство_товара1, свойство_товара_2 и т.д , а использовать при выборке только нужные поля.
Это ведет к тому, что у таблицы становиться очень много пустых полей... но есть большой плюс - удобство поиска, фильтрации и прочее.
Немного поразмыслив, в голову пришла идея оптимизации хранения свойств, путем ввода связующей таблицы, логика работы решается на стороне php.

Все товары с общими характеристиками хранятся в одной таблице product :
id, category_id, свойство_1 ...

Вторая таблица property (уникальные характеристики)
id, product_id, property_category_id , p_1, p_2, p_3 ...
Тут хранятся свойства товаров (1 товар - 1 запись). В поле property_category_id хранится идентификатор категории свойств , который назначается категориям товаров.
Например
category_id : телефоны
property_category_id : свойства_телефонов

Третья таблица хранит соответствие полей таблицы property и категорий свойств rel .
id , property_category_id, property_fields_name, name
property_category_id : свойства_телефонов
property_fields_name : p_1
name : емкость аккумулятора

Теперь мы создаем в таблице property 10 int, 10 varchar(255), 10 bool и т.д. И " связываем " через третью таблицу.
Если мы заходим в категорию телефоны, то для поиска и фильтрации нужно будет сначала сделать запрос в третью таблицу и на основе его сформировать SELECT



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

Сумбурно получилось. Может я где то ошибся или этот уже древний велосипед =)
Хочется обсудить, спасибо за внимание.

servit,
Приветствую, да конечно! Думаю что и эту проблему можно решить. Как вам сама концепция, я пока что похожего не видел.
Может я что то упустил ?

softwarer,
1) Спасибо , вторая таблица из за того что бы не дергать ее при выполнении простых действий и из за ограничений по количеству столбцов.

2) Отличия от EAV я считаю существенными (даже принципиальными - рост в ширину =) ), т.к. информацию о товаре получаем 2-мя простыми запросами.

3) Для "средней" гибкости, но производительной реализации каталога, если предположить, что на один товар будет приходится не более 100 числовых , 100 текстовых и 55 универсальных характеристик...

Конечно при большом количестве групп характеристик, работу начнет тормозить таблица rel.

Может есть похожие альтернативы, т.к. EAV не по душе мне?

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