La dimensione delle tabelle non è affatto una preoccupazione quando si deve scegliere tra le tecnologie. Come potrebbe influire sulla tua scelta? Quando puoi mappare e generare automaticamente le tue entità, non richiede nemmeno che tu scriva più codice standard quando scegli un ORM.
È piuttosto una questione sul compromesso tra la programmazione vicino al database e l'astrazione, sebbene entrambi possano essere mescolati.
In generale, a volte è meglio programmare vicino al database, ad esempio quando ci sono compiti critici per le prestazioni da soddisfare. Questo può essere fatto anche con Hibernate. A volte è troppo dispendioso in termini di memoria per recuperare intere entità o le query generate vengono eseguite troppo lentamente e hai bisogno di SQL personalizzato. Quindi è possibile utilizzare JDBC per questo, anche se Hibernate può interrogare il database utilizzando SQL nativo, anche.
Ci sono solo alcuni casi in cui scegliere JDBC su Hibernate, poiché l'astrazione di un ORM è di grande beneficio per un modello di programmazione pulito. Ad esempio, se avessi a che fare con un database legacy che si basa pesantemente su stored procedure che non possono essere realmente mappate alle entità. Quindi probabilmente è meglio non avere il livello di astrazione e utilizzare solo una tecnologia orientata ai risultati, come il semplice JDBC. Un altro punto per scegliere JDBC rispetto a Hibernate è quando si sta programmando vicino al paradigma relazionale. Oggetti / entità potrebbero essere nel modo di tali applicazioni. Tutto ciò che è molto orientato ai risultati potrebbe probabilmente essere implementato più facilmente usando semplicemente JDBC.
Conclusione
JDBC è migliore quando:
Tuttavia, quasi tutti gli altri casi sono trattati meglio con un ORM come Hibernate, poiché nei linguaggi orientati agli oggetti moderni il vantaggio della chiarezza del codice supera di gran lunga altri vincoli.