Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #6036

Re: Spring/hibernate and JDBC

From Arved Sandstrom <asandstrom3minus1@eastlink.ca>
Newsgroups comp.lang.java.programmer
Subject Re: Spring/hibernate and JDBC
References <3c16e5e7-3c0b-4126-9dd9-88f372a58f03@e26g2000prf.googlegroups.com> <ivamk9$dph$1@dont-email.me> <a8ce2398-e1f7-4dfd-966e-48e8daa03416@p10g2000prf.googlegroups.com>
Message-ID <W0gSp.58282$F25.57695@newsfe04.iad> (permalink)
Organization Public Usenet Newsgroup Access
Date 2011-07-10 08:27 -0300

Show all headers | View raw


On 11-07-09 09:32 PM, Jack wrote:
> On Jul 9, 4:01 pm, markspace <-@.> wrote:
>> On 7/9/2011 2:56 PM, Jack wrote:
>>
>>> With spring and hibernate so popular now, is there anybody still only
>>> use JDBC to write database application code? Thanks.
>>
>> I'm sure someone is, but yes I assume that JPA & Hibernate and
>> dependency injection frameworks like Spring and JSF have become the norm.
>>
>> Still good to know what JDBC is and does, since it's used by JPA and
>> Hibernate (et al.).
> 
> Is using JDBC to access database more efficient than using
> Spring/hibernate?

Define "efficiency". Is it runtime efficiency - knowing that you've got
the best possible SQL statement for actual load conditions - or is it
development efficiency - producing adequate DB access code in an
acceptable amount of team time?

There are a number of considerations that come into play. A major one is
the fact that only a minority of developers have sufficient SQL-fu and
also specific RDBMS knowledge to do a better job of writing SQL than a
JPA persistence provider like Hibernate or EclipseLink will. That's to
say, one does not usually observe that standalone native SQL written by
a given programmer is substantially better than the SQL generated from
EJBQL which is written by the _same_ programmer.

In fact, in a dev shop where coders are allowed too free rein to write
native SQL in a JPA context, their SQL is often worse than if they had
expressed their solution within the constraints of EJBQL. Unless they
are top-notch people.

With the latest JPA (version 2.x) there is also a type-safe criteria API
that offers more benefits than what the accessors available on JDBC's
ResultSet and PreparedStatement do. You can certainly do some typesafe
queries with JDBC's DataSet but at this point you're simply edging into
functionality that JPA takes for granted as basic.

In deciding what approach to take, I myself would not worry about
runtime performance excessively, at the gitgo, other than making sure
that regardless of whether the DB access code is in SQL or EJBQL, that
the coders are competent with the underlying fundamentals of accessing
an RDBMS. A coder who is not competent here will write an abortion
either way. To put it another way, the programmer should be capable of
producing good SQL, no matter what, but given that they may in fact
_then_ be better off writing EJBQL in a JPA environment.

Assuming basic competency, you'll really only discover at testing time
what DB accesses are not up to snuff in terms of performance. This would
be true for either straight JDBC (possibly using something like MyBatis,
though) or JPA with Hibernate or EclipseLink. At this stage of the game
your programmers may well engage the help of a DBA for some fine-tuning.
Much of the fine-tuning will have little to do with the actual SQL anyway.

Myself I tend to go with JPA 2, and only those DB accesses that either
cannot be fully expressed in EJBQL, and/or are complex enough that they
are better off in a stored procedure, usually end up in hardcoded SQL
someplace. Bear in mind that modern JPA persistence providers offer a
lot of customization features for finetuning, so it's rare to encounter
a _performance_ situation that forces you to use native SQL.

One larger consideration is persistence management. It is _both_ a pro
and a con of JPA that you place your persistent data, in the form of
objects, under the management of the persistence provider. This is such
a large topic that it's probably best the subject of another thread. But
it's absolutely an important factor in deciding between JPA and straight
JDBC.

AHS

Back to comp.lang.java.programmer | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Spring/hibernate and JDBC Jack <junw2000@gmail.com> - 2011-07-09 14:56 -0700
  Re: Spring/hibernate and JDBC markspace <-@.> - 2011-07-09 16:01 -0700
    Re: Spring/hibernate and JDBC Jack <junw2000@gmail.com> - 2011-07-09 17:29 -0700
      Re: Spring/hibernate and JDBC Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 17:55 -0400
    Re: Spring/hibernate and JDBC Jack <junw2000@gmail.com> - 2011-07-09 17:32 -0700
      Re: Spring/hibernate and JDBC Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-10 08:27 -0300
      Re: Spring/hibernate and JDBC Aéris <aeris@imirhil.fr> - 2011-07-10 13:33 +0200
      Re: Spring/hibernate and JDBC lewbloch <lewbloch@gmail.com> - 2011-07-11 11:25 -0700
        Re: Spring/hibernate and JDBC Aéris <aeris@imirhil.fr> - 2011-07-11 20:44 +0200
        Re: Spring/hibernate and JDBC Jack <junw2000@gmail.com> - 2011-07-11 16:39 -0700
          Re: Spring/hibernate and JDBC lewbloch <lewbloch@gmail.com> - 2011-07-11 17:06 -0700
            Re: Spring/hibernate and JDBC Gene Wirchenko <genew@ocis.net> - 2011-07-11 21:37 -0700
          Re: Spring/hibernate and JDBC Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-12 07:01 -0300
          Re: Spring/hibernate and JDBC Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 18:00 -0400
        Re: Spring/hibernate and JDBC Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 17:58 -0400
          Re: Spring/hibernate and JDBC Tom Anderson <twic@urchin.earth.li> - 2011-07-22 17:24 +0100
      Re: Spring/hibernate and JDBC Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 17:52 -0400
    Re: Spring/hibernate and JDBC Tom Anderson <twic@urchin.earth.li> - 2011-07-10 13:34 +0100
      Re: Spring/hibernate and JDBC Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-10 11:08 -0300
        Re: Spring/hibernate and JDBC Stanimir Stamenkov <s7an10@netscape.net> - 2011-07-10 17:45 +0300
          Re: Spring/hibernate and JDBC Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-10 17:35 -0300
      Re: Spring/hibernate and JDBC Steve Sobol <sjsobol@JustThe.net> - 2011-07-10 09:42 -0700
    Re: Spring/hibernate and JDBC Tom <tom400f@gmail.com> - 2011-07-10 22:29 +0000
    Re: Spring/hibernate and JDBC Gunter Herrmann <notformail0106@earthlink.net> - 2011-07-11 10:19 -0400
      Re: Spring/hibernate and JDBC Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 18:09 -0400
  Re: Spring/hibernate and JDBC Aéris <aeris@imirhil.fr> - 2011-07-10 13:24 +0200
    Re: Spring/hibernate and JDBC Elegie <elegie@anonymous.invalid> - 2011-07-10 13:56 +0200
      Re: Spring/hibernate and JDBC Aéris <aeris@imirhil.fr> - 2011-07-10 14:17 +0200
  Re: Spring/hibernate and JDBC Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-10 10:44 -0300
  Re: Spring/hibernate and JDBC Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2011-07-11 09:52 +0300
  Re: Spring/hibernate and JDBC lewbloch <lewbloch@gmail.com> - 2011-07-11 11:31 -0700
    Re: Derby and Java SE (was: Spring/hibernate and JDBC) lewbloch <lewbloch@gmail.com> - 2011-07-11 15:46 -0700
  Re: Spring/hibernate and JDBC iadb <freeinternetarticles@gmail.com> - 2011-07-17 10:17 -0700
  Re: Spring/hibernate and JDBC Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 17:47 -0400
  Re: Spring/hibernate and JDBC Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 18:02 -0400

csiph-web