This week's book giveaway is in the Reactive Progamming forum. We're giving away four copies of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams and have Adam Davis on-line! See this thread for details.
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.
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.
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!
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.
You'll never get away with this you overconfident blob! The most you will ever get is this tiny ad: