Hej, w przypadku gdy tabela w bazie ma wiele różnych kolumn lub joinów z dużymi ilościami danych, na ile dobrym sposobem jest tworzenie wielu encji i repozytoriów w Javie na różne cele?
Według mnie jest to słaby sposób. Jeśli tabela jest napuchnięta, to proponuję jakoś rozdzielić zarówno encję javową jak i tabelę w bazie, jako że powinny one być ze sobą 1:1
Hint: To że korzystasz z JPA nie powoduje że nie możesz korzystać z SQL "natywnego". Jak masz Springa to możesz użyc JdbcTemplate
Wiele różnych encji mapowanych do tej samej tabeli, to dobry pomysł tylko wtedy gdy mapujesz klasy, które dziedziczą po sobie. W przeciwnym wypadku zrobisz sobie kuku. Lecz głowa do góry, jeżeli masz bazę ze spartolonym modelem, to masz kilka opcji.
Projekcja i JPQL
Najprostsza metoda, bo pozwala na użycie wszelkich mechanizmów obecnych w JPA bez potrzeby angażowania SQLa
@Entity
@NamedQuery(name="KtoWydalRozkaz66", query="SELECT new pl.pakiecik.w.pakieciku.KlasaProjekcji(usr.name, ord.id) FROM User usr, Order ord WHERE usr = ord.author AND ord.val = 66")
class JakaśEncja{
//...
}
W tym momencie musisz mieć klasę KlasaProjekcji
, która w konstruktorze przyjmuje parametry zgodne z User.name
i Order.id
.
Native Query
Podobnie do powyższego, ale zamiast @NamdeQuery
możesz użyć @NativeNamedQuery
. Zapytanie piszesz w SQLu, co może być wadą, ale zaletą jest możliwość skorzystania z elementów specyficznych dla danego RDBMS.
Bardziej chodzi mi o to, że mam np. tabelę z id i jakimś symbolem, metadanymi i geometrią i klucz obcy do innej tabeli z geometrią - która zawiera dużo danych i czasem potrzebuje np. sam symbol, czasem metadane, geometrię, a czasem inne tabele z relacji i myślałem, że stworzenie różnych encji uprości kod - że łatwiej będzie się na to patrzeć