Do I need to use Hibernate or can I go with JDBC?

[Sriram Sharma]

Hi All,

Here below is the type of project that I am working on...

1. Only 2 tables are used
2. These two tables are like intermediate staging tables from where the data is later fetched, some operations done and transformed data is moved to a different system.
3. One of the table has a foreign key association with the other table. (One to Many mapping)
4. Caching is not required as it does not make much of sense for the project that I am working on
5. A sequence generator is used for each individual table
6. The contents of one of the tables is bound to go in millions

Considering the above points, is it wise to go with Hibernate?
One of my colleagues is saying that we can complete the tasks with JDBC itself.

We do not know how much changes may be required in future.

Regards,
Sriraam

[Bear Bibeault]

Of course you can use JDBC. You can use JDBC for any application.

Whether ti makes sense to adopt Hibernate instead is a different question. Is there a chance that the model will grow to a complex one?

[Mark Spritzler]

I am a huge proponent of Hibernate and JPA in general. But based on your description of what you are doing, I actually recommend using something like Spring Batch with Spring JdbcTemplate class to do the work.

If anything use JDBC and Spring's JdbcTemplate. You do not need to include all of Spring and an ApplicationContext if you just use the template and not Spring Batch. It is a simple class that only needs a reference to your DataSource object. But in the end it will save you from all the JDBC boilerplate code.

Friends don't let friends write straight JDBC code.

Mark

[Sriram Sharma]

Thanks Bear and Mark!
To answer it short, I am not sure how the table(s) may grow in future.
I was suggesting for a relational model rather than 1 or 2 table approach.
But for that, we do not have enough information and hence we are going with a 2 table approach where one table is a parent and the other is a child.
The child table is bound to get loaded with huge data.

Going with SpringJDBC - Let me see how that works for me.
Thanks for the advice and do keep me posted if any new suggestion strikes your brains!

Regards,
Sriram

[Kevin Embree]

One factor to keep in mind is performance, you mentioned millions of records.
Will you be revisiting the same records over and over again, and most are never (or rarely read) if so the caching in the ORM (hibernate) may be a big win.

If not, the caching won't help much.

Second will you be processing millions of records in a transaction, if so hibernate converting millions of records into objects and back will consume substantial amounts of memory and time. Using just jdbc could be a win in that case. (alternatively if you will be manipulating large numbers of records and are concerned about performance, moving the logic closer to the source (ie. stored procedure) could be very beneficial.

my 2 cents for what it's worth.