Czy są jakieś korzyści z używania @NamedQuery przez @NamedNativeQuery w hibernacji lub vice wersecie. nie mogę dostrzec różnicę lub dokładnie w jakim kontekście powinniśmy używać @NamedQuery ponad @NamedNativeQuery@NamedQuery nad @NamedNativeQuery
góry dziękuję.
@NamedNativeQuery pozwala pisać nazwane zapytania SQL, a @NamedQuery pozwala pisać nazwane zapytania HQL (lub JPQL).
Ogólnie rzecz biorąc, powinieneś preferować pisanie zapytań HQL, ponieważ wtedy możesz pozwolić Hibernate poradzić sobie z zawiłościami konwersji HQL na różne dialekty SQL. Ułatwi to twoją pracę, gdy zdecydujesz się na zmianę dostawców DBMS.
@NamedQuery należy skonstruować z użyciem języka zapytań (HQL lub języka zapytań trwałości). @NamedNativeQuery powinien być skonstruowany z natywnym SQL.
Podejmując się wykonania, musisz wiedzieć coś o tym, co dzieje się pod maską.
Prawdopodobnie programowałeś coś, używając prostego JDBC, więc wiesz, jak zapytać przejść do sterownika i wysłać do bazy danych. Podczas korzystania z HQL lub JPA-QL zapytania najpierw mają wartość , którą należy przeanalizować w języku SQL zrozumiałym dla bazy danych. W takim przypadku mamy do czynienia z dodatkowym krokiem analizowania . Należy zauważyć, że zapytania SQL, w tym wywołania procedur składowanych, struktura trwałości nadal zajmuje się odwzorowywaniem zestawów wyników JDBC na wykresy trwałych obiektów.
Jeśli chcesz dołączyć natywną podpowiedź SQL do instrukcji optymalizatora zapytań do systemów zarządzania bazami danych, na przykład , musisz napisać SQL samodzielnie. HQL i JPA-QL nie zawierają słów kluczowych.
Wadą natywnego SQL w metadanych mapowania jest utrata przenośności baz danych, ponieważ twoje mapowania, a więc i aplikacja, będą działać tylko dla określonej bazy danych. Ale zwykle jest to niewielka obawa, ponieważ prawdopodobnie nie tworzysz frameworka, które musi działać na każdej bazie danych.
Jeśli chcesz uzyskać dostęp do wydajności swojego zapytania, naprawdę musisz zapoznać się z bazą danych i spojrzeć na plan wykonania - DBA może powiedzieć dokładnie, co jest dobre i co można zoptymalizować.