Comments on: 5 Tips to be a Good JDBC Programmer

By: Frank Carver

Frank Carver — Thu, 16 Oct 2008 13:12:54 +0000

“Jim d.” wrote: “why pay for vendor-specific features unless you plan on leveraging them?”

My response is simple: “why pay for vendor-specific features?” If a lower cost (or free) solution meets the needs of the business, use it.

I am happy to pay for speed, robustness, scalability and general quality, but I want the ability to change vendor when a different product offers a better combination of these things.

Vendor-specific database features are simply the old “embrace and extend” technique to ensure lock-in, and the way to avoid that has always been to code to common standards.

By: Jim d.

Jim d. — Thu, 09 Oct 2008 20:28:28 +0000

I’m torn when it comes to tips #4 and #5. On one hand, I agree that it can be asking for trouble to rely on proprietary RDBMS features. On the other hand, why pay for vendor-specific features unless you plan on leveraging them?

By: Omar

Omar — Tue, 30 Sep 2008 16:40:18 +0000

As a former backend developer I have three comments:
- About Tip #3 & #5: In my experience repository never change “almost specific situations”, and this is always because of the money related to this change. So why not design to take advantage of that special feature Oracle or MySQL has.
- About Persistence Frameworks:
My first contact with Spring was because of the nice abstraction that brings JdbcTemplate. These kind of frameworks: SpringJdbc, iBatis, Hibernate, JPA, addresses diferent kind of problems (sometimes overlaps), but they bring a different level of abstraction, away from a bunch of boiler code that implies the use of JDBC.
- You forgot *TESTING*. This is a must in the persistence frameworks that I mentioned before.

By: Jeanne

Jeanne — Tue, 30 Sep 2008 00:58:30 +0000

I particularly like tip #2. An additional reason I like is the ability to pass in dates as objects rather than having to deal with database formatting.

By: scott

scott — Mon, 29 Sep 2008 22:22:11 +0000

Thanks Daniel,

It’s true batch PreparedStatement’s are excellent for bulk operations, but I tend to file those features under the category of ‘advanced JDBC’. The majority of beginner-to-intermediate JDBC programmers can get by without knowing much about them; unless of course your application is highly dependent on bulk operations.

By: Daniel Pietraru

Daniel Pietraru — Mon, 29 Sep 2008 22:15:58 +0000

Nice to the point article. I would add one more thing: use batch prepared statements for bulk operations.

By: Frank Carver

Frank Carver — Mon, 29 Sep 2008 22:02:59 +0000

And, I guess, consider using one of the many database frameworks and libraries which could help address lots of these points in one go.

By: scott

scott — Mon, 29 Sep 2008 21:13:46 +0000

Hi Alef,

Thanks for your comments. I do agree Spring makes a lot of JDBC programming easier, unfortunately the vast majority of JDBC developers still work with straight JDBC connections outside of any good framework. In fact, some JDBC programmers code from within JSPs (the horror!). Perhaps I should add that as a 6th tip.

By: Mittal

Mittal — Mon, 29 Sep 2008 20:51:16 +0000

Spring-iBatis and plain-iBatis also works very well – specially with existing database’s

I do agree – don’t use stored procedure unless really required to do some massive batch operations.

By: Alef Arendsen

Alef Arendsen — Mon, 29 Sep 2008 19:38:34 +0000

Hi Scott,

nice article. I don’t know if you have seen Spring’s JDBC template. It’s probably a pattern that has been implemented by many people before, but the application of the template/callback patterns make JDBC programming a breeze. In addition to everything you’re mentioning above, the JDBC template gives you exception translation as well, essentially preventing you from ever having to read another ORA error code again.

cheers,
Alef
Disclaimer: I do work for SpringSource