L_argoВвести новые данные - полдела. Нужно их научиться еще и вычитывать. Н-р в отчетах.
Я не уверен, что именно Вы подразумеваете под термином "вычитывать", но подозреваю, что как раз ту операцию, которая приведена в моём сообщении, и своей реализации которой Вы по понятным причинам не привели.

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

L_argo4. (профит)
Если это профит, не хотел бы я увидеть фейл.

L_argoЕсть унифицированный импорт ... Никаких новых таблиц. ... Не нужны админские полномочия ...
Вместо ответа на заданный вопрос Вы изображаете магнитофон, повторяющий заученные фразы.

ldfanateИнформационно-справочные системы, чтото типа "Центральный справочник материалов", - да наверное тут EAV чемто поможет, т.к. у разных групп номенклатуры МТР кардинально отличаются наборы характеристик.
Хотя бы простое в лоб поле "характеристики" типа XMLType поможет гораздо лучше.

ldfanateА оно поможет?
Ну.. мне достаточно сложно назвать задачу, в которой оно поможет меньше, чем EAV.

ldfanateВедь там не только сложная структура характеристик получится,
Сложная структура - это, скорее, фича. По крайней мере, в неё естественным образом укладываются составные характеристики, массивы и т. п. Да и верифицировать можно по xml schema, что по сравнению с eav - огромная прибавка к надёжности.

ldfanateно и потребность строить потом, при распухании справочника, специализированные индексы для ускорения поиска, - типа "дай мне всю номенклатуру товарного департамента N кроме гаек вида M".
Может быть. Но к таким объёмам EAV уже просто давно загнётся без вариантов, поэтому я не считал бы это сравнительным недостатком.

L_argoРеакция ожидаемая, но это реакция троля, а не инженера. Увы.
Ну конечно. Ваше "не трогай святое и любимое детище" - это реакция инженера, а моё "вот код", после которого Вам стыдно показывать свой - реакция тролля.

L_argoУ меня еще есть возможность
Смотрите. Ваше решение условно состоит из следующих частей. Во-первых, это API - то есть то, что "прикладной код" вызывает для реализации функционала. Во-вторых, некий движок метаинформации. И в-третьих, код реализации - то есть то, что получает команду в терминах метаинформации (например, "вернуть значение такой-то выборки" или "записать значение такого-то атрибута") и выполняет физический select, insert или update.

Представьте себе, что кто-то взял, добавил в метаинформацию данные типа "этот атрибут лежит в таком-то поле такой-то таблицы", а код реализации изменил таким образом, что вместо EAV тот начал работать с обычными плоскими таблицами. Если Ваше решение хорошо написано, сделать так вполне возможно и даже не особо сложно, верно? API при этом не изменилось, то есть приложение сможет работать с новой реализацией и даже не заметит подмену.

Так вот... мы говорим про EAV. Поэтому всё, что сохранится при такой подмене - к EAV уже не относится. Это функционал (хороший или плохой, удачно или неудачно реализованный) который Вы сделали, но который от EAV не зависит. В сравнении нас интересует то, что при такой подмене изменится - в лучшую или в худшую сторону.

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