JPA, anatywny SQL

Witam,
W ogólności JPA posiada kilka możliwości tworzenia zaptań: JPQL/Criteria Query oraz natywne query / named query.

Wiem, że skompilowane JPQL bywają szybsze niż ich natywne named query. Poza tym czysty SQL nie jest przenośny (ale to nie jest problem).

Interesuje mnie czy jest coś złego w używaniu natywnego SQLa w JPA? Czy to zła praktyka czy po prostu JPQL / Criteria Queries jest szybsze? Pytam, bo w niektórych projektach natywny SQL jest w sam raz. Tak samo jak procedury składowe w bazie. A w JPA 2.1 ich obsługa jest dość przyjemna. I nie wiem czy wybrać JDBC czy JPA/SQL.

Jakie są korzyści JPA/SQL nad JDBC?

Pozdrawiam,

Korzyści jakie dają Ci ORMy z stajni JPA:

• zapycha dziurę między modelem obiektowych a relacyjnym
• po części uniezależnia Cię do bazy danych - ale tylko po części
• w mniejszym lub większym stopniu dodaje cachowanie

To dosyć sporo jednak wbrew legendom nie odcina Cię w pełni od znajomości SQL oraz bazy jakie będziesz wspierał:

• w większych projektach pojawiają się bugi, które zmusza Cię do zejścia na poziom SQL
• migracje schematu wdrożonych bazy danych na nową wersję nadal musisz napisać sam w SQL, więc musisz wiedzieć jak struktura relacyjna wygląda
• optymalizacja bazy danych (indeksy, partycjonowanie) - w standardowym JPA nawet indeksów na ważnych kolumnach nie utworzyć, a trza to zrobić przecież.

Co do SQL vs JPQL: JPQL jest tłumaczony na SQL przez ORM - każdy co zna swój silnik bazodanowy to w SQL napisze wydajniejsze zapytania (przynajmniej te bardziej skomplikowane).
Jeżeli zależy Ci na przenośności to napisz wszystkie co możesz w JPQL - w SQL tylko te co wiesz że napiszesz wydajniej pod daną bazę danych.

Może napisałem trochę nieprecyzyjnie. Mam świadomość co robi JPA, dość sporo z tym pracuje (głównie JPQL i coraz częściej zapytanie natywne tam, gdzie nie potrafię inaczej albo jest to zbyt trudne).

Zależy mi głównie czy w ogólności warto pisać w JPA (natywnymi zapytaniami), gdy zależy mi głównie na natywnym SQLu. Domyślnym podejściem dla tego typu programowania jest JDBC. Kiedy JDBC wygrywa? Mi osobiście wydaje się, że JPA jest na tyle proste w konfiugracji i używaniu, że warto pisać @NamedNativeQueries i zapytania natywne, bo i tak zyskuje, chociażby na wydajności dzięki obecności cache (który zawsze mogę wyłączyć). Po prostu mniej się napracuje. Ponadto mam łatwiejszą obsługę transakcji (JTA/CMT).

Cache akurat nie ma nic wspólnego z zapytaniami - za każdym razem jak walniesz JPQLa lub SQLa to idzie flush i SQL bezpośrednio do i z bazy. Co do tego czy SQL w JPA to antypattern: jeżeli zależy Ci na przenośności między bazami danych i/lub twój zespół bardziej komfortowo czuje się z modelem obiektowy niż relacyjnym to TAK, w. p. w. NIE.

Jeżeli lubisz być bardziej przy modelu relacyjnym, a cache nie jest dla Ciebie kluczowym to zastanów się nad czym płytszym np. myBatis lub bardziej nakierunkowany na model relacyjny np. jOOQ. Bo implementacje JPA to mają kodu w milionach linii i bugi się znajduje podczas pracy w nimi.

Dzięki, pobawiłem się i znalazłem już satysfakcjonujące mnie rozwiązanie.

mógłbyś sprecyzować ?

Zintegrowałem JPA/EclipseLink i jOOQ. Wszędzie tam, gdzie to możliwe używam JPQL/Criteria Queries.

Po co mi jOOQ skoro używam JPA? Klient miał dużą fantazję i stworzył ciekawą strukturę tabel (dużo dziwnych widoków) i JPA nie dawało rady. Sam nigdy bym tak bazy nie zaprojektował, ale to nie zależało ode mnie. Potrzebowałem generować dynamiczne zapytania natywne (postgres). Normalnie użyłbym do tego celu Criteria Queries, ale tu nie było to możliwe.

Rozwiązaniem okazał się builder natywnych zapytań SQL z jOOQ. Za jego pomocą zwracam zapytanie SQL jako String, które ładuje do persistence managera jako native query. Mam odpowiednik Criteria Query dla rozwiązań natywnych.

Pozdrawiam,