Альтернатива EAV, структура базы?

Что значит «отрабатывает»? Запрос кэшированный или нет? Сравнивалась ли скорость с выборкой из обычной таблицы? Больше подробностей, пожалуйста.
Я Вам по опыту заявляю, что EAV это монструозный тормоз. Да и в теории, после прослушивания курса www.db-class.org/course/auth/welcome я могу добавить, что EAV это извращение вообще над идеей реляционных баз данных. Если недостаточно моего мнения, то почитайте здесь: en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model#The_critical_role_of_metadata_in_EAV_systems или здесь: stackoverflow.com/questions/tagged/entity-attribute-value?sort=votes&pagesize=50 ну или погуглите и почитайте о том, как сейчас авторы Magento мечтают избавиться от выбранной ими EAV.

Автору я уже тоже отвечал и советовал более подходящие БД (Mongo) или лучше продумать структуру БД, но, видимо, не хочется телодвижений и хочется убедить себя вопреки здравому смыслу (который однозначно автор осязает, иначе не спрашивал бы).

«Отрабатывает» значит выполняет sql запрос.

=> SELECT COUNT(*) FROM goods;
 count
--------
 250000
(1 row)
=> SELECT COUNT(*) FROM goods_option;
 count
-------
 10000
(1 row)
=> SELECT COUNT(*) FROM goods_option_link;
  count
---------
 2500000
(1 row)

EXPLAIN ANALYZE показывает. что запрос получения карточки конкретного товара (у которого 10 параметров) занимает ~0.15 мс. PHP часть думает больше, чем запрос отрабатывается в postgresql-е.

Я всяких умных курсов не слушал. Я инженер и решаю конкретные задачи в конкретных условиях. Бизнес мало интересуют эти технические заморочки. Но представителям бизнеса хочется любое количество типов товара с любым набором характеристик и так, что бы при появлении нового типа не приходилось привлекать разработчиков которые буду что-то там колдовать в структуру таблиц. И конечно же это должно быстро и безбагово работать при увеличении каталога до миллиона позиций.
Вот и я решаю эти задачи. Поэтому у меня простой PHP движок которые держит поток в 300 запросов/сек с времени генерации страницы ~0,015 сек долговременно (т.е. ~25 миллионов в сутки). На отрезке в 5 секунд он мог обработать кратковременный всплеск нагрузки до 1000 запросов/сек с генерацией
страниц ~0.070 сек. При этом PHP часть потребляет менее 200 МБ ОЗУ. В целом же вся связка nginx+php-fpm+postgresql+redis кушает ~1-1,5 Гб.

Если завтра изменятся условия которые покажут, что EAV мне не подходит, я без проблем применю более оптимальную структуру. И уж точно я ни когда не буду религиозным фанатиком кричащим: %username%, твой %lang% гавно и %struct% монструозный монстр потому как я инженер и практик. И критерий адекватности для меня — эффективное выполнение поставлено задачи, а не абстрактные рассуждения теоретиков.

Рассмешили кодом запроса, спасибо. После такого с Вами не о чем спорить, извините.

alekciy, вы продемонстрировали вырожденный случай EAV. В вашем случае понятие entity — вырождено т.к представленно обособленной таблицей. Подобные структуры называют UDA (user defined attributes) и, действительно, в них нет ничего страшного. В том смысле, что в этой модели еще можно использовать средства датабазы для контроля целостности, в отличии от классической EAV, где приходится целостность обеспечивать самостоятельно, а в условиях конкурентного доступа это вемьма и весьма не тривиальная задача, и решить ее эффективнее чем это делает СУБД для классической реляционной модели, порой, бывает просто невозможно.

Однако применимость такого подхода имеет ряд ограничений, в которые, вы, очевидно, вписываетесь. Но по вашему частному случаю, мне думается, рано обобщать. Действительно, получить карточку одного товара, используя данную струтуру не составляет проблемы. Но представить товарную иерархию в табличном виде это уже серьезная проблема, вам придется выполнить столько же джойнов, сколько атрибутов определено у сущности. Если вам нужно осуществлять отбор лишь по одному атрибуту или же по нескольким, применяя оператор OR к предикатам, то тоже проблем нет. Но если вам нужно отбирать по значениям нескольких атрибутов, к предикатам отбора применяя оператор AND, это становится весьма проблемотичным. Стоит так же отметить, что при таком подходе, определяемые пользователем атрибуты не могут быть использованы логикой приложения. Т.к. в жизненном цикле приложение код атрибута может быть изменен пользователем.

Но в том, что в EAV и в UDA действительно ничего нет ничего страшного, я с Вами полностью согласен. Просто эти структуры имеют ограниченную область применения. И если UDA еще можно где-то использовать, то область применения EAV — ничтожна. Это приложения, работающие с обособленными сущностями, модифицируемые в режиме монопольного доступа. Мне кажется эта область на столко узка, что случай, для которого подход EAV применим, вполне можно назвать исключительным.

>Действительно, получить карточку одного товара, используя данную струтуру не составляет проблемы.
Иерархия в отдельной таблице в виде AL или NS по ситуации. Связь с товар-лист_дерева через треть таблицу. Это покрывает текущие бизнес требования. В частности поиск по конкретным атрибутам не требуется, для интернет магазина одежды логика поиска «хочу красную рубашку ХХ размера» обычно приводит к быстрой выборке рубашек с использованием индекса и более медленной, но в рамках приложения быстрой, фильтрации по значениям атрибутов. Это с лихвой перекрывает текущие требования причем с большим запасом. Если бы это был каталог компьютерного оборудования с частым поиском по набору атрибутов, то конечно же такая структура бы не использовалась.

За наводку на UDA спасибо.