Skip to main content

Why JDBC

Posted by larryjava on June 18, 2012 at 4:52 PM PDT

Our Java application supports my company's (Amway Corp) Customer and Sales Compensation areas.
This is a very unique and complex part the Amway's business model.
The application requires a large database to store business-related data.
The database consists of dozens of tables and millions of rows.
It contains transactional data and summarized data.
The size of the database grows daily.
Database access is an important part of our Java application.
The application needs to do lots of complex data inquiry and data processing.

When our Java project began 10 years ago, we had to decide how to perform
database access from within the Java application.

Initially, we had the following factors to consider.
1) We had developers with SQL expertise gained from their work on legacy systems
2) We wanted to use core Java technologies
3) We wanted to take advantage of any industry standards on database access
4) We wanted direct control of SQL statements for performance tuning purposes

So we decided that JDBC (Java DataBase Connectivity) was the best fit, for us,
to do data access from our application.

We knew of other approaches to database access (object mapping, frameworks, other API's, etc.).
The other database access approaches were either too new or did not give us the skills we wanted our
developers to have.
It was a judgment call we felt pretty good about.

The Java training we received from our software tools vendor included JDBC lecture and lab sessions.
Everybody on the development team learned or re-learned about
JDBC connections, statements, result sets, etc.

How are things going with database access? Very successful.
Over the years, we have created a large number of data caching and data access classes
that are constantly being re-used and extended.

Not only are we using embedded SQL in Java code for database access.
In some cases we use database-specific "stored procedures" from our Java code.
We even experimented, briefly, with using Java "stored procedures" from within the application.

In the performance sensitive areas of the application, we have learned a great deal
about database access tuning with JDBC. This area continues to be a topic of great
importance to our application.
We are actively performance testing our application and tuning our database access.

JDBC. So far so good.

Comments

if you would face the same challenge today, would you still ...

if you would face the same challenge today, would you still choose JDBC, or would you consider some JPA implementation instead?

Thank you for your comment. Much appreciated. If we faced ...

Thank you for your comment. Much appreciated.
If we faced the same challenge today, we would probably choose a combination of approaches.
JDBC and a data access "framework" like JPA for instance.
Our requirements would be the same today as they were 10 years ago: utilize core Java technology, give our developers a useful set of data access skills, leverage existing data access skills where possible.

If you have only a few projects in your whole life and the ...

If you have only a few projects in your whole life and the project lifetimes are long (as in your case), then I think JDBC or a home-grown orm are good.

Good practical advise. It looks like the application is ...

Good practical advise. It looks like the application is practical and free of the latest buzzwords and hyped technologies. You only need to know SQL and Java to create applications rest of the layers can be avoided many times.