Я ищу возможные оптимизации для сгенерированных каркасом запросов. Насколько я понимаю, процесс выглядит следующим образом:

Вы можете объявить свои доменные объекты как POJO и добавить несколько аннотаций, таких как,@Entity@Table@ManyToOneи т.п.

вы объявляете свои репозитории, например по интерфейсам

С помощью (2) у вас есть несколько вариантов для описания вашего запроса: например, по методам или@Query

Если я напишу запрос, как:

@Query("select t from Order t LEFT join fetch t.orderPositions where t.id = ?1")
Page findById(Pageable pageable, String id);

SQL-запрос генерируется автоматически, где каждый столбец заказа разрешается и последовательно для позиций заказа и в зависимости от объектов / таблиц. Как будто я написал:

select * from order

Так на тот случай, что мне нужнонемного Информация отнесколько В соединенных объектах запрос может быть довольно дорогим, а более интересным - совершенно неэффективным. Я наткнулся на медленный запрос и MySQL-объяснение сказал мне, что вгенерироваться запрос оптимизатора не может использовать индексы, что плохо.

Конечно (я знаю), я должен иметь дело с компромиссом, чтогенерироваться SQL нетак оптимально, каквручную написано и имеет преимущество написания меньшего количества стандартного кода.

У меня вопрос: каковы хорошие стратегии для улучшения запросов, выполнение запросов?

Я подумал о некоторых вариантах сам:

1) Можно ли определить несколько "Сущности» для разных целей, напримерOrder для доступа кполный характеристики заказа и что-то вродеFilteredOrder с меньшим количеством столбцов и без разрешенияJoin-columns? Оба будут ссылаться на одни и те же таблицы, но один будет использовать все столбцы, а другой - только некоторые.

2) Использование@Query(... native="true") с выбором всех столбцов, которые я хочу использовать. Преимущество этого состоит в том, что я не буду удваивать свои доменные объекты и засорять свою кодовую базу сотнямиFiltered-Объекты. Как насчет подкачки? Используетpageable в комбинации с@Query( ...native="true") все еще возможно (я боюсь, что нет).

3) Последнее, но в моих глазахнаихудший"/ шаблонное решение: ИспользованиеJDBCTemplates и делать вещи на более низком уровне.

Есть ли другие варианты, которых у меня нет?думал? Спасибо за вдохновение на эту тему:]

Обновить: Наша текущая стратегия заключается в следующем

1) Где возможно, я работаю свыберите новый Как у менявидели, это работает для каждого объекта (будь тосущность или жеPOJO)

2) В сочетании с базой данныхПросмотры можно взять лучшее изSQL а такжеORM, Для некоторых случаев может быть интересно иметь агрегированный набор результатов под рукой. Определение этого результирующего набора в качестве представления упрощает с точки зрения БД просмотр результатов с помощью простогоВыбрать-заявление. Для стороны ORM это означает, что вы можете легко определить сущность, соответствующую этому представлению, и вы получите всюОРМ-благость сверху: пейджинг вкл.