Подходит ли Hibernate для пакетной обработки? А как насчет использования памяти?

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

Причины использовать Hibernate:

• «Кто-то» «творчески» подошёл к именам столбцов (PRXFC0315.XXFZZCC12).
• Дизайн БД все еще находится в процессе изменения, и/или вам нужно одно место, где имена столбцов сопоставляются с Java.
• Вы все равно используете Hibernate
• У вас сложные запросы, и вы плохо владеете SQL

Причины не использовать Hibernate:

• Остальная часть вашего приложения — чистый JDBC.
• Вам не нужны никакие возможности Hibernate
• У вас сложные запросы, и вы свободно владеете SQL
• Вам нужна определенная функция вашей БД, чтобы заставить SQL работать

Hibernate предлагает некоторые возможности для уменьшения размера сеанса.

Вы можете использовать Query.scroll(), Criteria.scroll() для JDBC-подобной прокрутки. Вы можете использовать Session.evict(объект объекта) для удаления объектов из сеанса. Вы можете использовать StatelessSession для подавления грязной проверки. И еще несколько оптимизаций производительности, см. документацию по Hibernate.

Hibernate, как и любой ORM-фреймворк, предназначен для разработки и поддержки систем, основанных на принципе объектно-ориентированного программирования. Но большинство баз данных являются реляционными, а не объектно-ориентированными, поэтому в любом случае ORM всегда является компромиссом между удобным ООП-программированием и оптимизированным/наиболее эффективным доступом к БД.

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

На мой взгляд, я бы НЕ использовал Hibernate, так как он делает ваше приложение намного больше и менее удобным для сопровождения, и у вас действительно нет возможности быстро оптимизировать сгенерированные sql-скрипты. Кроме того, вы можете использовать все функции SQL, поддерживаемые JDBC-bridge, и не ограничиваться функциями гибернации. Другое дело, что у вас тоже есть ограничения, связанные с каждым уровнем устаревшего кода.

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

Если есть возможные проблемы с производительностью, придерживайтесь кода JDBC.

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

Выберите только те столбцы, которые вы используете! (Нет "выбрать *" материал).

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

В зависимости от СУБД незначительное переупорядочивание SQL, где предикаты могут иметь большое влияние на производительность.

Если вы обновляете/вставляете только каждые 100-1000 обновлений. т. е. не фиксируйте каждую единицу работы, а сохраняйте некоторый счетчик, чтобы вы совершали реже.

Воспользуйтесь преимуществами агрегатных функций вашей базы данных. Если вам нужны итоги по коду DEPT, сделайте это в SQL с помощью " SUM (сумма) ... GROUP BY DEPT ".