Какие преимущества имеет HQL перед SQL для запросов Group By
Я концентрирую этот вопрос на запросах «отчетного типа» (count, avg и т. д., То есть на тех, которые не возвращают саму модель предметной области), и мне просто было интересно, есть ли какое-либо внутреннее преимущество в производительности при использовании HQL, как это может возможность использовать кеш второго уровня. Или, может быть, даже лучше - кешировать весь запрос.
Очевидное подразумеваемое преимущество состоит в том, что NHibernate знает имена столбцов, поскольку он уже знает о сопоставлении модели.
Есть ли другие преимущества, о которых мне следует знать?
[Я использую NHibernate, но предполагаю, что в данном случае то, что применимо к Hibernate, будет в равной степени применимо и к NHibernate]
Ответы 4
HQL - это язык объектных запросов. SQL - это язык реляционных запросов.
Для отчетов вы можете использовать SQL.
Нет никаких преимуществ. HQL не превзойдет прямой запрос к базе данных для агрегирования данных и вычислений. Результат примерно такой:
Select count(*), dept from employees group by dept
Всегда будет работать быстрее в БД, чем в HQL. Заметьте, я говорю всегда, потому что глупо придерживаться принципа мышления «зависит от вашей ситуации». Если это связано с данными и агрегированием данных; сделайте это в SQL.
Собственно .. вы знаете, что такое HQL? Выбранный вами вариант, написанный на HQL, просто вернет тот же самый SQL, который вы указали. Он не делает этого в памяти!
Запросы HQL, такие как select avg (cat.weight), sum (cat.weight), max (cat.weight), count (cat) из Cat cat, не получат никаких «преимуществ» производительности по сравнению с «raw SQL». Те преимущества в производительности, на которые «надеялись» в этом вопросе, не будут реализованы. Это основная тема моего ответа.
Объекты в кэше второго уровня извлекаются только по идентификатору, поэтому Hibernate всегда будет запускать запрос для получения списка идентификаторов, а затем читать эти объекты либо из кеша второго уровня, либо с помощью другого запроса.
С другой стороны, Hibernate может кэшировать запрос и полностью избегать вызова БД в некоторых ситуациях. Однако вы должны учитывать, что изменение любой из таблиц, участвующих в запросе, сделает его недействительным, поэтому вы не можете часто попадать в кеш. См. здесь описание того, как работает кеш запросов.
Таким образом, стоимость вашего запроса равна либо 0, если запрос кэшируется, либо примерно такой же, как при выполнении запроса в прямом SQL. В зависимости от того, как часто изменяются ваши данные, вы можете значительно сэкономить, включив кеширование запросов, или ничего не сохранить.
Если у вас большой объем запросов и вы можете терпеть устаревшие результаты, я бы сказал, что намного лучше использовать другой кеш для результатов запроса, срок действия которого истекает каждые x минут.
Единственное преимущество, о котором я могу думать, заключается в том, что запросы ORM обычно кэшируются на (подготовленном) уровне оператора, поэтому, если вы выполняете один и тот же запрос много раз, скорее всего, вы повторно используете подготовленный оператор.
Но поскольку вы просили конкретно о отчеты по запросам и производительности, я не могу придумать никаких преимуществ практичный (я замалчиваю тот факт, что у вас есть другие преимущества, такие как согласованность доступа к данным, запросы ORM по сравнению с SQL (в большинстве случаев проще написать запрос с HQL), преобразования типов данных и т. д.)
Спасибо за понимание. А теперь не могли бы вы попытаться ответить на актуальный вопрос.