вадяandreykaTвадя,

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

Как по мне - это фраза из разряда "программировать или верстать нужно в блокноте". Просто более высокоуровневые фреймворки нужно изучать и разбираться, что происходит от того или иного действия. А иначе получается преждевременная оптимизация, а это очень большое зло. У меня на прошлой работе были программисты старой школы которые на JDBC + собственное ручный DAO слой исполдьзовали везде. Так они эту часть писали в 3 раза дольше, чем другая команда использующая ORM и в узких местах написавшая native query.

вадя,

И хотел бы добавить, что если уж нужно сохранить перфоманс, то и для этого существуют фреймворки которые снимают часть руттиной работы (тот же mybatis или spring jdbc template)

вадяandreykaTвадя,

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

Если можете подкрепите примером. Какую структуру можно создать вручную и нельзя сгенерировать по entity? Естественно, что бы это давала какие-то весомые плюсы.

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

Читать форум как справочник вряд ли буду. Я не спорю, что делая минимум настроек оставляя все по дефолту в том же hibernate можно получить тормоза, но эти тормоза как правила решаются более правильно настройкой ORM. То есть тут все упирается в знания. Естественно за универсальность ORM нужно платить и на хайлоаде такое не прокатит, но для больше части проектов в самый раз.

вадяавторЕсли можете подкрепите примером. Какую структуру можно создать вручную и нельзя сгенерировать по entity? Естественно, что бы это давала какие-то весомые плюсы.
к примеру для интернет-магазина - произвольное количество свойств для любого товара, с возможностью организовывания фильтров
по любому из них

Entity
Good
- propertyValue (one to many)

PropertyValue
- propery (many to one)
- value
- good (many to one)

Property
- name

И запросы hql к entity PropertyValue
Как-то так должно прокатить, я не понял в чем тут подвох.

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

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