JPA czy natywny SQL z JDBC

Odpowiedz Nowy wątek
2019-08-19 10:43
0

Kiedy używać JPA a kiedy natywnego SQL z JDBC? Powiedzmy mamy system który ma szybko zapisywać do bazy i jakąś warstwę prezentującą wyniki w takim przypadku powinniśmy użyć natywnego SQL z JDBC czyli dla każdej "encji" mieć składanie INSERTA? natomiast warstwa prezentująca może już używać JPA?

Pozostało 580 znaków

2019-08-19 15:41
0

dobra zadam pytanie w inny sposób, bo nie chodzi mi czy uciągnie czy nie.
Czy natywne sql przez JDBC są szybsze niż używanie JPA+jakiegokolwiek ORM? :)

Pozostało 580 znaków

2019-08-19 15:50
3

JDBC bedzie szybsze w znakomitej wiekszosci przypadkow, jesli chodzi o odpowiedz na Twoje pytanie.
Tylko musisz sobie odpowiedziec na pytanie, czy zysk wydajnosciowy z tego tytulu bedzie wiekszy niz straty z wolniejszego developmentu.

Pozostało 580 znaków

2019-08-19 15:52
3

Jeżeli robisz tylko i wyłącznie zapytania i wszystkie mapowania wszywasz na sztywno w kod w miejscu tworzenia zapytań, to tak. JDBC będzie szybsze.

Pozostało 580 znaków

2019-08-19 18:19
0

Dzięki za odpowiedzi :) Wiem że w tym przypadku wydajność będzie kosztem developmentu.

Pozostało 580 znaków

2019-08-19 19:20
xy
0
dargenn napisał(a):

Tylko musisz sobie odpowiedziec na pytanie, czy zysk wydajnosciowy z tego tytulu bedzie wiekszy niz straty z wolniejszego developmentu.

W większości przypadków raczej: czy zysk będzie miał jakiekolwiek znaczenie w porównaniu ze skutkami sp...nej struktury fizycznej po stronie bazy danych. ;)

I dlatego właśnie powstały ORMy, by odseparować struktury w bazie od modelu obiektowego. Niestety jakieś 90% użytkowników nie wychodzi poza podstawowe mapowania. - Koziołek 2019-08-19 20:42
@Koziołek: W prawdzie od ponad 2 lat nie pracowałem z orm jak hibernate, ale z czystej ciekawości podasz jakieś bardziej zaawansowane mapowania? - podroznik 2019-08-19 20:56
Użycie @Embbeded, @SecondaryTables/(s) czy ww. construction queries, to rzadkość. Do tego masz jeszcze konwertery i możliwość zmiany nazw atrybutów. A pomimo tego i tak większość projektów próbuje robić OOP w bazie lub relacyjność w modelu OO. - Koziołek 2019-08-19 21:00
A to @Embbeded znam i korzystałem z reszty nie. W każdym razie dzięki doczytam sobie. - podroznik 2019-08-19 21:11
Mnie to nawet nie chodziło o to, że model w bazie danych musi być zły, jeśli jest bliski tego obiektowego. ORM właściwie mapuje na model logiczny po stronie bazy danych, a jego realizacja w strukturach fizycznych może być różna i jest cały arsenał dostępnych środków, np. index-organized tables, clusters (Oracle), różne rodzaje partycjonowania itd., a nie tylko: wolno działa? "zausz" indeks. ;) Bierze się to chyba z niewystarczającego przyłożenia się do tematu przez brak mody na to i głębszej wiedzy. - xy 2019-08-19 21:14
@xy: to nie jest kwestia mody, ale ogromu wiedzy do przyswojenia. Nie sposób ogarnąć wszystko :) ale próbować można :D - Koziołek 2019-08-19 21:33

Pozostało 580 znaków

2019-08-20 14:12
0

Świeża anegdota z życia, z morałem

Do instalacji 'biznesowej' której jestem 'ojcem', by nie powiedzieć głównym projektantem, kilka lat temu dopuściłem podwykonawcę/kolegę.Ponieważ uprawia język odchodzący w niszę, postanowiliśmy, że będzie insertował do surowej tabeli. Co do reguł biznesowych obiecaliśmy, że "będziemy pamiętać i uważać". Właśnie serwisuję bazę MSSQL, bo dokument który miał się nie zrobić w niedzielę, jednak się dał zrobić, w tym wdrożeniu akurat na to DUŻE znaczenie. Naruszenie zasad biznesowych - kilka lat później - się stało mimo obietnic.

Morał: ja Cię proszę ;) użyj klas i lekkiego mapera,ale utrzymaj kontrolę logiczną. Po załadowaniu klas, spreparowaniu SQL-i i rozgrzaniu się na pierwszych rekordach będziesz miał czas nieodróżnialny od surowego JDBC, ale większą kontrolę logiczną

UPDATE: https://github.com/bwajtr/jav[...]istence-frameworks-comparison

edytowany 1x, ostatnio: AnyKtokolwiek, 2019-08-20 16:24

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0