Database development
in [Java Programming]
|
Prev: Null pointer issues
Next: Urgent
From: Jack on 25 Apr 2010 01:03 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? Thanks. Jack
From: Arne Vajhøj on 25 Apr 2010 10:37 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 Arne
From: Lew on 25 Apr 2010 12:08 Jack wrote: >> When I work on database development projects, I use JDBC and SQL. Many >> people use hibernate [sic]/spring [sic]. Can somebody explain the pros and cons of >> using JDBC and SQL vs using hibernate [sic]/spring [sic] on database >> developments? Arne Vajhøj wrote: > 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 Hibernate, as Arne pointed out, is not the only ORM (Object-Relational Mapping) tool. The biggies include also OpenJPA and EclipseLink. They all support and implement the Java Persistence API (JPA), the Java standard for ORM. JPA is useful for more than mere CRUD, but that is the most common use case. JPA does not require Spring at all. "Hibernate/Spring" is not one thing nor one word. Strictly speaking, JPA is not for database development. It is for persistent object development. The point of view of JPA is object orientation, quite different from the set logic of SQL. SQL is best when you need a relational view of data. JPA is best when you need an object view of objects. Obviously JPA sits atop JDBC, so there is no real dichotomy between the two. The question is roughly equivalent to the decision between a low-level library and a higher-level one. -- Lew
From: Tom Anderson on 25 Apr 2010 12:14 On Sun, 25 Apr 2010, 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 I'd rephrase that slightly to say that ORM is best when you want to deal with your data as objects - when you need to be able to call methods, traverse object graphs, and generally think of your data as objects. If your data is something that isn't usefully thought of as objects (perhaps a big boring spew of temperature measurements over time or something) then there isn't much benefit to ORM. There's probably no real harm either, so if you prefer ORM, you can still use it. 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. tom -- The literature is filled with bizarre occurrances for which we have no explanation
From: Zlatko Duric on 25 Apr 2010 12:44
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? TIA -- Zlatko |