You do add at least one extra statement to your code for each column you access this way. Of course this doesn’t add that much ‘reading overhead’, but then again, even for bulk reads the performance gain typically isn’t that much either, if any. Just try it

A lot depends on your context. Please also read what I have to say about such micro optimizations in http://jdevelopment.nl/java/java-best-practices-4-native-arrays-and-not-using-java-5. This case is actually the same kind of tradeoff as using native arrays vs arraylists. The former is theoretically faster, but most businesscode is not going to be influenced by that. The bottomline is; if you have actually used a profiler to ‘prove’ that accesses by name are indeed a bottlenneck in your application, by all means, access by index. But please don’t sacrifice readability in your code for an ‘premature optimization’ which may have zero impact.

>the best practice to be used for bulk data is to retrieve the result set metadata, ask for the index of the interesting columns by column name and then use the index to get data

This is an intermediate solution. It’s atleast a lot better than only using hardcoded index references in your code On the other hand, this does add some slight complexity to your code and degrades the readability slightly. The performance gain is also very minimal. Most (nowadays all?) JDBC drivers use a fast HashMap for looking up the columnname. So, per getter you would safe one hash lookup. On modern computers and for typical business code this is absolutely nothing. Even if you were doing thousands of such lookups, the effect would be barebly noticable, if at all.

The tradeoff here is between a minimal performance gain and better readability of code. Would you like to have a 0.00001 second shorter execution time, but in case of a bug somewhere have your technicians spend 2 minutes more on reading the code, and have a 30 percent higher chance of misinterpreting the code when under presure? Of course everyone should make that decision for himself, although I think most businesses are better off to go for readability (and maintainability first and then optimize proven bottlenecks when they emerge.