Recently I came across a BLOG entry on the internet and the guy has a point.
I copy-pasted his article to custommode.com wiki (just in case the url changes).
http://jroller.com/page/jojopaderes/20041027The article follows:
O/R Mapping Tools vs DB Stored Procedures
With the releases of efficient O/R (Object/Relational) mapping tools (Hibernate, Ibatis, and Cayenne), and the common belief among Java developers that J2EE is the solution to all enterprise IT needs, developers have always argued to database admins that using stored procedures in database will spell countless refactoring, endless maintenance, incorrect modelling of the business domain or whatever. On the other hand, database admins will argue that Java is a slow language and using O/R mapping tools is an added layer of waste and inefficient use of the database. Just use stored procedures for everything that's used in the database since it's more efficient and fast (true in some cases but not always).
This is a classic win-lose scenario in a project where Java developers and database admins are in constant struggle which design approach is more efficient. Two design items are compromised here: (1) the effective implementation of domain business codes or logic which is the forte of OO languages such as Java, and (2) data integrity logic which is best implemented on the database.
In my opinion, the best approach would be to identify where O/R mapping and stored procedure implementations are suited. Dealing with large amount of data are better left with stored procs. Business or domain logic are effectively handled by using Java and nicely-written frameworks such as
Spring and
Hibernate. That is why both frameworks still support stored procedure calls on database to harness the fast and efficient data manipulation. Data manipulation should not be confused with business logic implementation, which is evident in a database-centric application.
O/R mapping tools are very efficient (in the case of
Hibernate) when doing redundant queries on the database instead of using plaing JDBC codes. I wrote a simple application that queries some data from three relational tables. I implemented a plain-and-stupid-try-catch-everything JDBC code, Spring JDBCTemplates, and Hibernate. The JDBC code is the slowest, Spring was twice much faster than the latter, while Hibernate outperforms both implementation 10 more (and sometimes more than that). Optimization, as promised by Hibernate, is only done through re-configuration of the mapping config file and Hibernate implementation (I used Spring IoC for this). I didn't bother using the EJB crap here since there's no need to use remote kung-fu and the overhead of using such technology on a simple task (that's a tip for a corporate J2EE developer).
