JDBC VS HIBERNATE

W jakim sensie wydajniejszy?

Szybkość wykonywanych operacji.

1. Hibernate działa na bazie JDBC
2. Nie da się tego stwierdzić, bo wszystko zależy od tego co programista tam napisze. Generalnie na niskim poziomie oba rozwiązania opierają się o to samo, więc mogą być równie (nie)wydajne.

Z hibernatem może być taki problem że jest dużo "magii" i jak człowiek nie ogarnia to może to łatwo wywalić. A co do Jdbc jest alternatywa np. w postaci JdbcTemplate springowego który eleminuje boilerplate code :)
Generalnie jak stosuje się ORMy to można to tez mieszać z natywnym SQLem, np. ORM się fajnie nadaje do zapisu/edytowania/kasowania encji, ale często stosowanie zwykłego SQLa może być lepsze...

Oba są tragicznie wolne. Jak chcesz szybko to nie używaj bazy danych.

Mając hibernate można łatwiej popełnić błąd i zrobić coś bardzo niewydajnego. I to nie tylko sławne n+1. Można np. spartolić equals/hascode i nieźle ubić wydajność.

Z drugiej strony w hibernate łatwiej jest zrobić cache, a jak wiadomo zwykle najszybciej to jest nie czytać nic z bazy.

Gołe Jdbc jest smutne. Są jeszcze inne alternatywy: jooq, mybatis itd.

Tak czy siak zwykle 99% pytań co jest szybsze nie ma sensu. Przy wyborze technologii nie tym się powinieneś kierować.

Korzystanie z gołego JDBC pozwala na dużo swobodniejsze wykorzystanie różnych smaczków w SQL, co pozwala czasami napisać szybciej wykonujące się zapytanie, albo pominąć mapowanie do obiektów, ale to jeszcze trzeba mieć trochę doświadczenia z bazami danych, żeby coś takiego wyszło.

Dodatkowo. W przypadku młodego programisty (juniora) szansa na zrobienie sobie SQL injection, przy korzystaniu z gołego JDBC wynosi 115%. W przypadku hibernate troche trudniej.

Żeby zrozumieć, na czym polega różnica, należy zrozumieć, jak działają bazy danych, na poziomie komunikacji z aplikacjami. W dużym uproszczeniu każda baza danych wykorzystuje swój protokół komunikacyjny, w ramach którego przesyła zarówno zapytania SQL, parametry zapytań, jak i dane oraz metadane wyników.

####JDBC

JDBC jest specyfikacją, która opisuje w jaki sposób Java „rozumie” komunikację z bazą danych. Jednocześnie JDBC ujednolica, po stronie javy, sposób komunikacji. Implementacją JDBC są sterowniki, które zazwyczaj są pisane przez twórców baz danych. Te sterowniki widać w kodzie w momencie nawiązywania połączenia:

public Connection getConnection() throws SQLException {

    Connection conn = null;
    Properties connectionProps = new Properties();
    connectionProps.put("user", this.userName);
    connectionProps.put("password", this.password);

    if (this.dbms.equals("mysql")) {
        conn = DriverManager.getConnection(
                   "jdbc:" + this.dbms + "://" +
                   this.serverName +
                   ":" + this.portNumber + "/",
                   connectionProps);
    } else if (this.dbms.equals("derby")) {
        conn = DriverManager.getConnection(
                   "jdbc:" + this.dbms + ":" +
                   this.dbName +
                   ";create=true",
                   connectionProps);
    }
    System.out.println("Connected to database");
    return conn;
}

DriverManager utworzy, bazując na tzw. connection string, połączenie, którym musimy ręcznie zarządzać.

Czym zatem jest Hibernate, czy też szerzej JPA?

To też widać w powyższym kodzie. Ale po kolei. O ile JDBC tłumaczy struktury bazodanowe takie jak wyniki (ResultSet) na proste typu danych Long, String itd. to Hibernate pozwala na kolejny krok, czyli przetłumaczenie jak pojedyncze rekordy wyników tłumaczą się na złożone obiekty. Oczywiście działa to dwukierunkowo, czyli możemy przetłumaczyć nasze obiekty na tabele w bazie danych oraz opisać, w jaki sposób referencje pomiędzy obiektami (na poziomie definicji klas) są przedstawione w bazie danych (zależności pomiędzy tabelami). Oczywiście to nie wszystko, ponieważ tego typu funkcjonalność jest dość prosta w implementacji i zazwyczaj projekty wykorzystujące JDBC w jakiś sposób implementują też mapowania. Wartością dodaną w przypadku JPA jest warstwa abstrakcji, która pozwala na zmianę bazy danych bez zmiany zapytań. Jako że bazy danych różnią się składnią SQL, to zmiana implementacji RDBMS pociągała, by konieczność przepisywania zapytań SQL (w momencie wykorzystania JDBC). Hibernate/JPA ograniczają pracę do zmiany w konfiguracji. To jak Hibernate tłumaczy model obiektowy na model w konkretnej bazie danych nazywamy dialektem. Dobrze to widać na kodzie powyżej, gdzie za pomocą ifa chcemy obsłużyć dwa różne RDBMS. Efektywnie, jeżeli nasze zapytania inaczej wyglądają w każdym z tych systemów, to musimy obsłużyć to w kodzie kolejnymi ifami (albo stosować różne kombinacje wzorców). JPA zamknie nam to w konfiguracji dialektu.
Kolejna sprawa to zarządzanie połączeniami, które jest automatycznie ogarnięte przez Hibernate oraz cache.

I na tym właśnie polega różnica:

• JDBC opisuje, jak java komunikuje się z bazą danych i w jaki sposób typy z bazy danych mapują się na proste typy javy i dostarcza spójny interfejs do komunikacji z różnymi bazami danych, ale obsługa różnic jest po stronie programisty.
• JPA opisuje, jaka jest zależność pomiędzy złożonymi typami po stronie javy, a tabelami i typami w bazie danych.
• Hibernate jest implementacją JPA, która zajmuje się ogarnięciem różnic pomiędzy poszczególnymi RDBMS oraz zarządzaniem połączeniami.

Wybaczcie, że odkopuję ale mam pytanie w temacie: jak oceniacie czy umiejętność posługiwania się gołym jdbc przyda się nabyć w kontekście juniora?
Nie ukrywam, że do tej pory używałem JPA i nie zagłębiałem się niżej.

Jak klepiesz CRUDa, albo generalnie potrzebujesz zmapować sobie całą bazę to spoko, JPA czesto starczy. Ale może chcesz tylko puścić jakieś ciekawe query na bazie, z grupowaniem, agregacjami etc i potem odczytać wynik do jakiegoś customowego obiektu. Wtedy JPA w niczym nie pomaga, a raczej tylko przeszkadza. Oczywiście może lepiej jakieś Spring JDBC Template a nie gołe JDBC, ale sama umiejętnośc pisania SQLa nie zaszkodzi nikomu.

Areek napisał(a):

Wybaczcie, że odkopuję ale mam pytanie w temacie: jak oceniacie czy umiejętność posługiwania się gołym jdbc przyda się nabyć w kontekście juniora?
Nie ukrywam, że do tej pory używałem JPA i nie zagłębiałem się niżej.

Do zapisów/update'ów lepszy jest ORM, do odczytów i skompilowanych raportów HQL, JPQL, typowany JOOQ lub lekki nakładki jak JDBI i JdbcTemplate. Goły JDBC to strasznie dużo klepania niepotrzebnego kodu.
Więc jak w firmie składają dużo tabel żeby zrobić raport to SQL się przyda, ale gołego JDBC lepiej unikać

Areek napisał(a):

Wybaczcie, że odkopuję ale mam pytanie w temacie: jak oceniacie czy umiejętność posługiwania się gołym jdbc przyda się nabyć w kontekście juniora?
Nie ukrywam, że do tej pory używałem JPA i nie zagłębiałem się niżej.

Rozumiem, że pytanie nie tyczy się SQL vs ORM tylko przydatność znajomości JDBC .

Odpowiedź - JDBC to dośc skomplikowany twór, gdzie trzeba pamietać o zamykaniu Statementów, utrzymywaniu puli połączeń, sprawdzaniu wasNull na ResultSet i wielu innych dziwactwach.
łatwo się pomylić i doprowadzić do wycieku zasobów lub wprowadzić podatność na SQL Injection.
Wolałbym abny juniorzy się w to nie bawili, a i seniorzy nie za często. JDBCTemplate czy inne template ze Springa i podobnych to juz dość niebezpiecznie niski poziom, niżej lepiej nie schodzić.

Ostatnio odkryłem jeszcze coś co się nazywa Speedment: https://speedment.com/

Disclaimer: Nie używałem tego na PROD.

Podobnie jak w JOOQ / QueryDSL generujemy API z istniejącej bazy danych. Tyle, że wygenerowane API ma formę Stream API z JDK8.

Zalety:

• type safe API
• brak wysiłku z kopiowaniem nazw kolumn do kodu,
• generuje eleganckiego CRUDa (persist, merge etc.)

Wady:

• Nie akceptuje javax.sql.DataSource tylko tworzy własną wewnętrzną pulę połączeń. Jeżeli ktoś ma skomponowane DataSource np. do monitoringu, transakcji etc. to słabo,
• Transakcje obsługiwane są podobnie jak w Springowym TransactionTemplate,
• Powyższe wady powodują, że nie możemy tego dodać transparentnie do aplikacji Springowej.

JDBC jako takie warto poznać, nawet będąc juniorem. Kwestia tego, żeby nie robić wielkich oczu, jak zobaczy się kawałek kodu. Trochę innym zagadnieniem i mam wrażenie, że to jest sens pytania, to znajomość SQLa. Ta jest wymagana na poziomie co najmniej podstawowym już na początku zabawy z programowaniem za pieniądze.

jarekr000000 napisał(a):

Mając hobernate można łatwiej popełnić błąd i zrobić coś bardzo niewydajnego. I to nie tylko sławne n+1. Można np. spartolić equals/hascode i nieźle ubić wydajność.

Co masz na myśli wspominając o tym equals/hashcode?

@Belka: Hibernate/JPA wykorzystuje equals i hashCode w wielu operacjach związanych z porównywaniem encji. Zła (typowa) implementacja tych metod może spowodować dużo problemów. Począwszy od spadku wydajności, poprzez nieprawidłowe wyszukiwania, a na wielokrotnych insertach tych samych encji kończąc. Ładnie opisane tutaj

Hibernate:

• wygodniejsze API
• wersjonowanie encji i blokowanie zapisu przy probie nadpisania czyjejs zmiany
• auto-wykrywanie zmian i aktualizacja tylko wybranych pol
• Criteria. API pomaga gdy masz wygenerowac rozme warunki w tym samym miejscu w zaleznosci od parametrow wejscia ( jest to malo czytelne ale bezpieczne)

JDBC:

• wygodniejsze API do zlozonych raportow (agregacje, zagniezdzenia)
• latwiejsze do nauki dla juniora
• bezposrednia kontrola zapytan SQL (czyli ich postac jest gwarantowana) - to jest przydatne gdy chcemy optymalizowac po stronie bazy

@nie100sowny:
Fajne narzedzie. Uzywalisny kiedys. Zdecydowanie najszybsze i ladne. Nawet szybsze od sqla niekiedy.