поскольку пишу 2-й раз — буду краток ;) не буду пугать количеством реализованных «складов», сразу приведу пример довольно универсального справочника товаров (естественно, в упрощенном виде ;)
Таблица 1 — goods:
id, Name
Таблица 2 — params:
id, Name(например — Производитель, Длина, )
Таблица 3 — goods_params:
id, goods_id(foreign key), param_id(foreign key), Value

в такой схеме товар имеет имя(в некоторых случаях его можно генерить автоматом по заполненным данным из goods_params — будет как общее описание товара в розетке), а все его характеристики в goods_params, пустых полей нет, добавление товара с новыми характеристиками добавит записей в goods, params, goods_params. В ширину таблицы расти не будут. Надеюсь, схема понятна? Ключи/индексы не расписаны… Дальше это можно наворачивать еще долго… проблем с подбором, поиском и сопоставлением товара здесь нет — решается банально через SQL(что-то вроде расширенной версии такого подхода отлично работает в оракловой базе под 1,5TB). ну а насколько данная фантазия ляжет на ваш orm — это другой вопрос — вы не это спрашивали ;)
ну где хранить цену — вопрос обычно отдельный ;) хотя, в некоторых случаях войдет в уже описанную схему… в общем, дерзайте ;)

не выдержал, пришел еще раз… ;) я читаю что мне пишут а вы не читаете даже себя ;) если написано «Для обычного поиска по названию товара придется делать массу телодвижений» а подразумевается что-то другое то тут только телепаты помогут угадать ;) а я своих телепатов по мелочам не беспокою ;) так что ответил на то, что написано а не подразумевалось ;)
вы опять демонстрируете не понимание работы с бд на достаточно свободном уровне ;) это, как говорится без обид, но факт ;) дабы продемонстрировать часть ваших заблуждений, обращу внимание на такой факт что понравившееся вам слово EAV, принципиально не мешает вам работать в дальнейшем с данными так, как будто они хранятся в flat table ;) т.е. можно получить выборку вида:
goods_id, goods_name, param1, param2, pram3,…
где будут те самые пустые поля если данного атрибута нет у товара. к такому набору данных вы сможете применять банальный select ;) гибкое хранение на то и гибкое, дабы не ограничивать в дальнейшей работе (привет от К.О. ;). ответ на вопрос как сделать такую работу более комфортной, несколько зависит от применяемой СУБД и задач, но обычно подойдет view(а вы их вообще пробовали использовать?)…
ну, еще можно сделать умное лицо и спросить про перфоманс такой схемы ;) зная предпологаемый размер таблиц, тип субд, используемое железо, а в некоторых случаях и количество пользователей — обычно легко ответить — справитесь? :)