• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

stored procedures vs JDBC batch updates

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1. In a given transaction, if I need to insert/update few records (say around 5 records) in different tables (say around 5 tables), can someone tell me which is the best approach to follow: JDBC batch updates or stored procedures?

2. We are going to use Hibernate3.0 in our project. In that case which is the prefered solution: Using JDBC batch updates through Hibernate or using stored procedures through Hibernate?

Thanks
Sivaraman
 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
depends on your performance needs

for 5 records for 5 tables, executing sql statements should be no problem.

if you are writing some financial application that needs to do this thousands of times per minutes then stored procs are always the fastest means of executing crud to the database.

if milliseconds don't mean much to you, then hibernate will make your code much more manageable going forward with changes and extensions to your codebase since then you have the means to create model objects and map your database tables in hbm.xml files and simple write code thats as simple as.. er um.. hey lets even use Spring as a framework! ::



hibernate is pretty well designed so that it doesn't add much overhead versus using raw JDBC. the only reason to not use hibernate would be if you truely need the speed of stored procs, or your database is so old and legacy with no good indexing or ids, hibernate becomes a pain to do true mappings. hibernate simply loves good data models.
 
sivaraman syntel
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the details. We have planned to use Spring also.
 
reply
    Bookmark Topic Watch Topic
  • New Topic