Ох, не хотел я ввязываться в спор о том, когда стоит/не стоит использовать ОРМ решения... Но раз уж ввязался, попробую ответить...

Я считаю, что при принятии такого архитектурного решения нельзя опираться только на отдельные характеристики проекта (объем данных, количество пользователей, "плотность потока" запросов и т.д. и т.п.). Необходимо расматривать проект в целом. Вот пример:

svenomnotpolymerЕсли это интернет-проект с тысячами юников в день - то с базой лучше сразу "руками" (тобишь через голый JDBC) работать.
...

Ну давайте разбираться. Несколько тысяч уников - пускай 5000 тысяч. День - 16 часов (8 спим). 5000/16 = 300 запросов в час = 1 запрос в 10-12 секунд. Тут 20 Хибер наложенных друг на друга справятся.

Вроде логично - сейчас 5000 уников, вроде небольшая нагрузка... А теперь вспоминаем контекст - речь идет об интернет проекте, а такие проекты, если добиваются популярности, обычно испытывают взрывной рост нагрузки. Т.е. сейчас у вас 5 тысяч уников, а через пол года 105 тысяч уников. И все, что можно сделать во время "взрыва" - это судорожно втыкать новое железо в кластер и проводить точечный тюнинг. И тут прирост производительности в 10-15% тормозящего запроса может сыграть решающую роль.
А стратегический рефакторинг можно будет провести только после испытания "взрывом"... Причем сильно после...

Другой пример:
BlazkowiczУ нас тоже хибер на высоконагруженом проекте. Толстый кэш и рассинхронизация клиентских запросов с БД дают отличный запас по производительности. Перевод на JDBC это экономия на спичках. Можно там выжать какие-то миллисекунды, но если проект не масштабируется, то и отказ от ORM не спасёт.
Вроде история успеха, но... Давайте копнем чуть глубже... В данном случае "узким" местом системы является СУБД. Какие есть основные методы обхода такой проблемы:
1) Классический тюнинг sql запросов - как на уровне базы (исследовали план запроса, добавили/убрали индекс, денормализовали схему, разнесли таблицы и индексы по разным табличным пространствам на разных физических дисках ну и т.д. и т.п. по Кайту...), так и на уровне запроса (изменили структуру запроса, добавили хинты, изменили алгоритм выборки, изменили бизнес-логику чтобы упростить запрос и т.д. и т.п.)
2) Кластеризация СУБД - добавили master-slave репликацию данных. Проиграли на записи, зато круто выииграли на чтении. Я думаю очевидно, кто кластеризация "среднего" звена - сервера приложений - тут не поможет.
3) Кэширование данных на уровне "среднего" звена - сервера приложений, и кластеризация сервера приложений (пожалуй, наиболее эффективный способ из перечисленных 3х).

Судя по словам Blazkowicz'а "Толстый кэш и рассинхронизация клиентских запросов с БД" команда проекта пошла третьим, наиболее эффективным путем. А теперь давайте посмотрим, какие нужны условия, чтобы пойти этим путем:
1) Бизнес логика приложения должна позволять кэширование данных, вносящих наибольший вклад в нагрузку на СУБД.
2) Чтобы реализовать корректный, горизонтально масштабируемый кэш, и не поломать бизнес логику и целостность данных в СУБД необходимо, чтобы над проектом работали достаточно высококвалифицированные разработчики, с высокой степенбю "прямизны рук" так сказать.
3) Чтобы в проекте появились высококвалифицированные разработчики необходим просто нормальный менеджмент, который умеет выполнять свои основные обязанности - найм исполнителей, делегирование задач, высокоуровневый контроль над проектом.

Пункт 1 обычно не вызывает больших проблем. Пункт 2 - тут конечно со скрипом, ибо обезьянок много, а хороших разработчиков реально мало. А пункт 3 в российской действительности практически не выполним. Ну не бывает у нас нормального менеджмента. Не видел я его. Всегда действуют по принципу "как бы чего не вышло". Наймут кого подешевле (а то наймем за большие бабки, а он все равно не справится), не сумеют делегировать технические задачи соответствующим специалистам ("Какой такой расперделенный кэш? Вы обалдели? Нам тут рокет сайенс не нужен - делайте как попроще!"), устроят микромэнеджмент ("Как, Вася потратил целых полтора часа на рефакторинг?!!! Вы обалдели - у нас через месяц релиз!!! Какой нафиг рефакторинг, откатывайте все обратно!!!") ну и т.д. и т.п.

Понимаете мою мысль? Т.е. затюнить проект с помощью кэша далеко не всегда получится - по чисто субъективным причинам. А на СУБД кластер могут тупо денег не дать. Вот и приходится по старинке выжимать микросекунды из запросов.

svenomСмех да и только.
Кому смех а кому слезы. Проекты обычно приходится выполнять с теми разработчиками и тем начальством, которые есть сейчас. И далеконе всегда "правильное" с теоретической точики зрения техническое решение будет наилучшим для конкретного проекта. А поиск наилучшего решения - всегда компромис. И ОРМ вполне может пасть жертвой этого компромиса - даже если теоритически он подходит для проекта на все 100%

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

svenomБез обид, но ваши высказывания по поводу российского менеджмента, выдают в вас человека, которому не доводилось работать в нормальных конторах, и который склонен обощать свой неудачный опыт на всю отрасль.
Я сотрудничал с 3мя компаниями, 1 забугорная, 1 полу-забугорная, 1 русская. Ничего из того, что вы написали про менеджмент, не встречал. Что я делаю не так?
Началось... Собственно поэтому я и не лезу тут в споры...
Работал я в разных конторах - и в нормальных, и в ненормальных, и в наших и в западных... И опыт свой мне сложно назвать неудачным - с пяток успешных крупных проектов и только 1 откровенный провал. По мелочи я не считал.
Как тут дальше доказывать, что я не верблюд - я не знаю. Резюме публиковать как то не хочется. Регалиями трясти тоже. Так что я лучше вернусь в read only режим. Т.к. все, что можно было сказать по сути вопроса я сказал. Добавить мне нечего.

svenomКак стыкуются вот эти два утверждения?
notpolymerНу не бывает у нас нормального менеджмента. Не видел я его.notpolymerИ опыт свой мне сложно назвать неудачным - с пяток успешных крупных проектов и только 1 откровенный провал.
Как написано, так и стыкуется. Я менеджментом проектов никогда не занимался. И не собираюсь. Проекты выполнял в роли Senior/Tech Lead/Architect.
Пока.

DPH3При этом, конечно, я понимаю, что моя любовь упаковывать сложные сущности, не нужные на уровне БД (например, существенные только целиком на уровне АппСервера или вообще нужные только для визуализации) в блобы - это тоже такой ORM, просто очень специфический. Ну, правда, у меня всегда есть отмазка - получение объекта из блоба заметно быстрее загрузки результата сложного join.

Такой подход тоже имеет право на жизнь, но с ним лучше вообще отказаться от реляционных СУБД, и посмотреть в сторону NoSql. Не стоит есть суп вилкой.