Mad_Head Как сказать не сталкивался... Я крутился вокруг подобных проблем 7 лет работая 1с-ником, причем базы бывали на столько огромные, что часто приходилось прибегать к работе с БД средствами SQL минуя ORM 1c. Приходилось заниматься оптимизацией, но более низкоуровневой чаще всего анализ начинался с просмотра плана запроса и лога блокировок, джависты, как правило, такие темы не обсуждают. По этой причине как решить задачу средствами jdbc я довольно хорошо представляю, структура БД из моего поста выше подошла бы, нужно только энтити на таблицы заменить. Опыта в JPA у меня меньше по этому я и общаюсь в данной теме, что бы выяснить для себя почему вы считаете, что JPA не пригодно для такой вполне просто задачи. И если вы знаете почему, то вполне смогли бы предоставить кейс. К примеру "не получится 1 запросом выбрать список товаров по набору характеристик/свойств" - просто лакончино и без юления. Я даже буду готов проверить ваше утверждение.

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

авторМэд, только что глянул ваше решение. лол. вы просто в гуд по сути добавили лист пропертей. а лист может быть длиной... если не ошибаюсь. два в 32й степени. Вадя, тебе хватит пропертей? :)
тут дело не в количестве, а в том как эти свойства назначить конкретному товару, как организовать фильтрацию, как организовать отображение, добавление и прочее, прочее. и учесть при этом быстродействие.
к примеру , модно хранить набор свойств у товара в поле в виде такого набора 34,5,6,...
где числа - id свойств.
всё красиво, но только до тех пор пока не надо организовывать поиск по свойствам, сортировку, красивый вывод....
при малых объёмах это не заметно , но при настоящих объёмах данных - это уже тормоза.

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

mayton,
там хорошо описали проблему свойств. но решение очень частное. я б не стал на него ориентироваться.

andreykaT,
это для каких целей?

авторты озвучивал задачу найти товар, подходящий под какие-то свойства.
я озвучил задачу создание системы для работы со свойствами товаров.

maytonвадяmayton,
там хорошо описали проблему свойств. но решение очень частное. я б не стал на него ориентироваться.
Там просто не учтен поиск непрерывных величин типа цена, вес, габариты но их
можно учесть на 2-й фазе поиска типа JOIN id-s товаров полученых из Редис
с MySQL.
начнёш это реализовать - получится велосипедостроение....

авторв чем проблема?

я озвучил задачу: создание системы для работы со свойствами товаров.
ты же вырываешь из системы кусочек и его решение выдаёшь за решение для всей системы.

DPH3mayton,

у меня вот возникала задача поиска по 1e6 товаров (до 1e9 атрибутов), с поиском по совпадению, по диапазону и т.п, еще и с нормальными требованиями по производительности (10ms на запрос). Никакая СУБД, увы, не справляется и близко, нужно писать собственное решение (впрочем, писать его недолго).
интересно,
но после опытов с mysql 5.7.11 с поиском по like среди 1е7 записей я не уверен что всё так трагично
хотелочь бы посмотреть. есть возможность 1е6 товаров дать для тестов?

DPH3,
длина поля названия ? структура таблицы? прочие условия?
чтоб было реальное сравнение скорости.