Database development
in [Java Programming]
|
Prev: Null pointer issues
Next: Urgent
From: Robert Klemme on 25 Apr 2010 14:30 On 04/25/2010 04:37 PM, Arne Vajhøj wrote: > On 25-04-2010 01:03, Jack wrote: >> When I work on database development projects, I use JDBC and SQL. Many >> people use hibernate/spring. Can somebody explain the pros and cons of >> using JDBC and SQL vs using hibernate/spring on database >> developments? > > That is a rather big discussion. > > The ultra short version is: > - ORM (Hibernate or other) is best when the problem to > be solved is CRUD of objects > - pure SQL (JDBC) is best when you want to do something > more unusual Notably manipulating large volumes of data. While there are some features in JPA and likes working efficiently with large volumes of data often requires exploiting features of the particular RDBMS at hand. That soon becomes awkward if you want to do it through a ORM. And one downside of using Hibernate, JPA or any other ORM tool: these tools hide the often quoted impedance mismatch between the object world and the database - which is good because that is precisely what they were invented for. The danger here is to use a persistent store mindlessly just like objects in memory which has a good chance of leading to awful performance in certain situations. In a way you could say the hiding works but not for every use case and sometimes you're crossing from "works" to "major nuisance" without noticing it. Bottom line, with Hibernate as well as with any other tool, you should know it and its weaknesses (which to a certain extent makes the "hiding" moot). Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
From: Arne Vajhøj on 25 Apr 2010 20:14 On 25-04-2010 14:30, Robert Klemme wrote: > On 04/25/2010 04:37 PM, Arne Vajh�j wrote: >> On 25-04-2010 01:03, Jack wrote: >>> When I work on database development projects, I use JDBC and SQL. Many >>> people use hibernate/spring. Can somebody explain the pros and cons of >>> using JDBC and SQL vs using hibernate/spring on database >>> developments? >> >> That is a rather big discussion. >> >> The ultra short version is: >> - ORM (Hibernate or other) is best when the problem to >> be solved is CRUD of objects >> - pure SQL (JDBC) is best when you want to do something >> more unusual > > Notably manipulating large volumes of data. While there are some > features in JPA and likes working efficiently with large volumes of data > often requires exploiting features of the particular RDBMS at hand. That > soon becomes awkward if you want to do it through a ORM. > > And one downside of using Hibernate, JPA or any other ORM tool: these > tools hide the often quoted impedance mismatch between the object world > and the database - which is good because that is precisely what they > were invented for. The danger here is to use a persistent store > mindlessly just like objects in memory which has a good chance of > leading to awful performance in certain situations. In a way you could > say the hiding works but not for every use case and sometimes you're > crossing from "works" to "major nuisance" without noticing it. Bottom > line, with Hibernate as well as with any other tool, you should know it > and its weaknesses (which to a certain extent makes the "hiding" moot). I don't think the big benefits of ORM (Hibernate or JPA or one of the alternatives) are in the writing of the code. It still requires somebody that knows both the ORM framework and the database well to write really efficient code. The big benefits are for reading the code. Everyone can read the the code using ORM and immediately understand what it does without looking at tons of code that uses JDBC and SQL. It is maintenance friendly. Arne
From: Jack on 25 Apr 2010 22:57 On Apr 25, 9:58 am, Arne Vajhøj <a...(a)vajhoej.dk> wrote: > On 25-04-2010 12:44, Zlatko Duric wrote: > > > > > On 04/25/2010 06:14 PM, Tom Anderson wrote: > >> And as Arne said, when you're trying to do something unusual, you may be > >> outside the limits of what ORM can comfortably do, and you'll be better > >> off using straight JDBC. Or perhaps a combination of ORM for any CRUDdy > >> / domain logicky bits, and JDBC for complex queries. > > > I inherited something that uses Hibernate, and I'm thinking about > > speeding up a few things. I was just thinking about how it would be > > difficult to try to speed all the slow stuff up by replacing all the > > hibernate stuff with all JDBC queries, and with my experience there's no > > chance I'll be doing this. But this approach (combination of ORM and > > JDBC) sounds very interesting to me. > > > Now, my data is all objects - that suits me perfectly. But there is some > > information about all those objects I'd like to store in a single table > > or maybe two of them, that'd be super-fast to reach, without having to > > look for all those parent/children/node/parameters/other links and > > without having other issues to think about. I believe that part of the > > features would benefit from it a lot in terms of performance. > > > Now, how common is this approach (combination)? Is there something > > really important I should read about this, before starting with the > > implementation? > > If you are accessing the data as objects, then I don't think > that switching from Hibernate to raw JDBC is the right direction > to optimize the code. > > Instead you should focus on tuning Hibernate and the databases > itself. > > Hibernate can be slow and Hibernate can be fast. It all depends > on the guy writing the code. > > Arne To use JDBC and SQL, I need to handle trial things, like commit, rollback etc. How about hibernate/spring?
From: Lew on 25 Apr 2010 23:52 Jack wrote: > To use JDBC and SQL, I need to handle trial things, like commit, > rollback etc. How about hibernate [sic]/spring [sic]? Hibernate and Spring are two completely different products. In Hibernate and other JPA products you do have to handle transactions. I don't know about Spring. -- Lew
From: Zlatko Duric on 26 Apr 2010 02:40
On 04/25/2010 08:09 PM, Lew wrote: > Zlatko Duric wrote: >>>> But there is some information about all those objects I'd like to >>>> store in a single table or maybe two of them, that'd be super-fast to >>>> reach, without having to look for all those >>>> parent/children/node/parameters/other links ... > > Wrong approach. Well, I don't mean to change the model. I want to keep and use all this stuff that's already in there. But there are few things I think can benefit from an approach like this: - reports there are a few "reports" being produced from the system. For some 10000 objects, there are 200k mysql queries - I am not much into big systems (yet) but this seems waaaaaaaaaaay too much to me. If I had the data from this in an additional table (I know this means duplicating some data), I could filter out what I need in one single query. - lists when accessing the data, users only fetch a certain small amount of objects - 15, 20, maybe 100 at a time. So to avoid most of the node links and stuff, I could get a quick filter of the data needed, without having to join this and that. Now, I know there are some disadvantages too, like having to worry whether I update the object and the table at the same time or so. I also have to make sure that all the data is in sync, since it's now duplicated. But I still can't resist wondering if this would be a good option. Luckily I still have a couple of months work already planned, so I get to think about it :P Thanks anyway -- Zlatko |