Pyatochkin

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

поскольку пишу 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 — это другой вопрос — вы не это спрашивали ;)
ну где хранить цену — вопрос обычно отдельный ;) хотя, в некоторых случаях войдет в уже описанную схему… в общем, дерзайте ;)

пипец писал полчаса и все пропало :( ох уж эти веб редакторы… еще вернусь…

к сожалению, правильный ответ — читать о проектировании БД вообще и нормализации в частности… один из критериев «правильной структуры» БД — это то, что ваши таблицы не растут в ширину при добавлении новых свойств для ваших объектов (в вашем случае — это св-ва товаров). Соответственно одним из критериев «плохой структуры» будет множество пустых в большинстве записей полей, сделанных «про запас». Ну а то, что хранение данных в БД, связи между таблицами и т.д. НИКАК не должны ограничивать отображение — это легко понять, взглянув на описание паттерна MVC. В общем обычно, оправдан такой подход — нормализуем БД до предела, продумав рост (по возможности, конечно ;). Тогда при достаточном знании SQL нет проблем что-то найти ;) Если у вас реляционная БД и вы хотите работать только через ORM, нигде не кастомизируя запросы, то вы не всё сможете реализовать…

P.S. все ваши 3 варианта, как бы это сказать, не по фэншую ;)