Comments on: 5 Tips to be a Good JDBC Programmer

By: Mistakes Java Developers Make when Writing SQL – Deep Coding Experience and Knowledge for Sharing

Fri, 14 Oct 2016 10:12:51 +0000

[…] this mistake or misbelief still surfaces blogs, forums and mailing lists many years after the appearance of JDBC, even if it is about a very […]

By: Lukas Eder

Lukas Eder — Mon, 12 Aug 2013 09:23:58 +0000

Much of your post makes sense, but #5…

> you can’t even recall exactly what they did when you wrote them.

If you cannot recall that, then you probably cannot recall what table X and table Y were supposed to mean. Then you might as well just dump all data into a single clob and full-text search for it… 😉

Seriously, that is really not a good reason not to use stored procedures.

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.