Я ищу возможную оптимизацию для запросов, сгенерированных каркасом. Насколько я понимаю, процесс следующий:
-
вы можете объявить объекты домена как POJO и добавить несколько аннотаций, таких как
@Entity,@Table,@ManyToOneи т.д. -
вы объявляете свои репозитории, например. на интерфейсы
С (2) у вас есть несколько вариантов описания вашего запроса: например. за имена методов или @Query
Если я напишу запрос, например:
@Query("select t from Order t LEFT join fetch t.orderPositions where t.id = ?1")
Page<Order> findById(Pageable pageable, String id);
SQL-запрос автогенерируется, где каждый столбец порядка разрешен и подпоследовательно для ордеров и зависимых значений/таблиц. Как будто я написал:
select * from order
Итак, в случае, если мне нужна информация из нескольких связанных объектов, запрос может быть довольно дорогостоящим: и более интересным является весьма неэффективным. Я наткнулся на медленный запрос, и MySQL объяснил мне, что в сгенерированном запросе оптимизатор не может использовать индексы, что плохо.
Конечно (я знаю) Мне приходится иметь дело с компромиссом, который сгенерировал SQL не так оптимально, как написано вручную, и имеет преимущество написания менее шаблонного кода.
Мой вопрос: какие хорошие стратегии для улучшения запросов, выполнения запросов?
Я подумал о некоторых вариантах:
1) Можно ли определить несколько "Объектов" для разных целей, например Order для доступа ко всем характеристикам порядка и что-то вроде FilteredOrder с меньшим количеством столбцов и без разрешения Join-columns? Оба будут ссылаться на одни и те же таблицы, но каждый будет использовать все столбцы, а другой только некоторые.
2) Используйте @Query(... native="true") с выбором всех столбцов, которые я хочу использовать. Преимущество этого было бы в том, что я не буду удваивать свои доменные объекты и помещать свою кодовую базу сотнями Filtered -Objects.
Как насчет пейджинга? Использование pageable в сочетании с @Query( ...native="true") все еще возможно (я боюсь, что нет).
3) Последнее, но в моих глазах "худшее" решение: используйте JDBCTemplates и делайте материал на более низком уровне.
Есть ли другие варианты, о которых я не думал? Благодарим вас за любое вдохновение в этой теме:]
Update: Наша текущая стратегия следующая
1) По возможности я работаю с выбором нового Поскольку я видел, это работает для каждого объекта (будь то Entity или POJO)
2) В сочетании с представлениями базы данных можно взять лучшее из SQL и ORM. Для некоторых случаев, представляющих интерес, может быть интересен совокупный набор результатов. Определение этого набора результатов как вида облегчает работу с db-перспективой, чтобы наблюдать результат с помощью простого оператора select. Для ORM-стороны это означает, что вы можете легко определить объект, соответствующий этому представлению, и вы получите полное ORM-доброту сверху: Paging, включая
