Szukam możliwych optymalizacji dla zapytań generowanych przez framework. O ile rozumiem, proces jest następujący:

możesz zadeklarować obiekty swojej domeny jako POJO i dodać kilka adnotacji@Entity, @Table, @ManyToOneitp.

deklarujesz swoje repozytoria, np. na interfejsy

Za pomocą (2) masz kilka opcji opisujących zapytanie: np. na nazwy metod lub@Query

Jeśli napiszę zapytanie, takie jak:

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

zapytanie SQL jest generowane automatycznie, gdzie każda kolumna zamówienia jest rozwiązywana i kolejno dla pozycji zamówienia i zależnych obiektów / tabel. Jakbym pisał:

select * from order

Więc na wypadek, że potrzebujętrochę Informacja zkilka połączone obiekty, zapytanie może być dość drogie: i bardziej interesujące jest dość nieefektywne. Natknąłem się na powolne zapytanie, a wyjaśnienie MySQL powiedziało mi, że wwygenerowane zapytanie optymalizator nie może wykorzystać indeksów, co jest złe.

Oczywiście (wiem) muszę sobie z tym poradzićwygenerowane SQL nie jest tak optymalny jakręcznie napisane i mają tę zaletę, że piszą mniej standardowy kod.

Moje pytanie brzmi: jakie są dobre strategie poprawy zapytań, queryexecution?

Myślałem o kilku opcjach osobiście:

1) Czy możliwe jest zdefiniowanie kilku „Jednostek” dla różnych celów, takich jakOrder za dostęp dopełny cechy zamówienia i coś takiegoFilteredOrder z mniejszą liczbą kolumn i brakiem rozdzielczościJoin-columns? Oba odwoływałyby się do tych samych tabel, ale jedna używałaby wszystkich kolumn, a druga tylko niektórych.

2) Użyj@Query(... native="true") z wyborem wszystkich kolumn, których chcę użyć. Zaletą tego byłoby to, że nie podwoiłbym moich obiektów domenowych i nie zaśmieciłby mojego kodu bazowego setkamiFiltered-Obiekty. Co z stronicowaniem? Jest używanepageable w połączeniu z@Query( ...native="true") wciąż możliwe (boję się nie).

3) Ostatnie, ale w moich oczach „najgorsze” / podstawowe rozwiązanie: UżyjJDBCTemplates i robić rzeczy na niższym poziomie.

Czy są inne opcje, o których nie pomyślałem? Dziękujemy za inspirację na ten temat:]

Aktualizacja: Nasza obecna strategia jest następująca

1) Tam, gdzie to możliwe, pracuję zwybierz nowy Tak jak jawidziany, działa to dla każdego obiektu (czy to jestJednostka lubPOJO)

2) W połączeniu z bazą danychwidoki możliwe jest wykorzystanie wszystkiego, co najlepszeSQL iORM. Dla niektórych przypadków użycia może być interesujące posiadanie zagregowanego zestawu wyników. Definiowanie tego zestawu wyników jako widoku ułatwia oglądanie wyniku z perspektywy bazy danychWybierz-komunikat. Dla strony ORM oznacza to, że można łatwo zdefiniować jednostkę pasującą do tego widoku i uzyskać całośćORM-dobroć na górze: Stronicowanie w tym