createQuery против createNativeQuery, разница в производительности для операторов обновления/удаления

Есть ли разница в производительности между:

entityManager.createQuery("UPDATE MyTable SET coll1 = :someValue").setParameter("someValue").executeUpdate();

и

entityManager.createNativeQuery("UPDATE MyTable SET coll1 = :someValue").setParameter("someValue").executeUpdate();

и если да, то достаточно ли он высок, чтобы использовать один подход вместо другого?

Я сравниваю производительность между спящим режимом и ядром фреймворка. В ядре EF такие вещи можно сделать только с помощью собственного SQL (ну, есть сторонние библиотеки), поэтому я хочу знать, должен ли я отключить все createQuery().executeUpdate() для createNativeQuery().executeUpdate() на мой спящий проект.


java hibernate sql native-sql bulkupdate
person M364M4N cro    schedule 01.01.2020    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Как и все в этом роде, вы должны протестировать свои данные и свою систему.

Однако интерфейс createNativeQuery() предназначен для того, чтобы вы могли напрямую вызывать SQL, а не через сопоставление ORM. Здесь у вас есть простой оператор обновления, поэтому сгенерированный SQL должен быть очень близок к собственному SQL.

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

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

person Gordon Linoff    schedule 01.01.2020