По скорости с prepared statement в абстрактной БД особой разницы быть не должно, чтобы не канкатенировать строки можно попробовать обновить джаву там в новых версиях вроде есть текстовые блоки по типу как в питоне
если этот селект сделать вьюхой (если он реально сложный), то разница между запросом из view и запросом через prepared/native/jpa в разы отличается
Для любой БД? Это случайно не матерелизованный view в Postgres (или аналоги в других СУБД)?
Интересно я про это не знал. А чем это вызвано? Насколько я знаю в pg если это не материализованная вьюха он просто сделает подстановку в запрос, скомпилирует и построит план
в постгрес create view, затем маппишь сущность на нее и делаешь запросы с любыми фильтрами какими хочешь
ты по сути делаешь запрос из готовой таблицы, которая обновляется по триггерам (вроде как) то есть она всегда готова и всегда актуальна инфа про скорость проверена лично на работе, запросы под 300 строк с кучей джоинов, case then и тд
так это материализованная
Это материализованное представление, использовать которые не надо вообще.
нет) строится через CREATE VIEW
материализированное - CREATE MATERIALIZED VIEW у меня - CREATE VIEW
Обычно между селектом и вьюхой нет разницы в производительности, но если фильтруешь вьюху - надо проверять, что предикат корректно пушится внутрь того запроса, который используется во вьюхе.
Почему нельзя? Из-за того что его надо рефрешить? Или есть еще какие то подводные камни?
Посмотрите план разбора запроса и запроса из представления. Скорее всего, разницы не будет. Но Java тут не при чем. А вы зачем хотите сделать это функцией? Чтобы несколько раз в коде не писать - есть NamedQuery
вьюху можно загнать в сущность JPA и фигачить запросы через репозитории)
речь о трехзначных запросах
Обсуждают сегодня