1. Intro
Note that for the time being, it is pretty much a "how to get JDBC working"
FAQ, but hopefully as time goes on will grow in scope.
Post them to the newsgroup. Don't e-mail me. I won't answer direct e-mail questions. I will only answer newsgroup posts, if I know the answer or have a good guess. Other people may know the answer better than me, or they may just have free time sooner than I do. Share your questions and answers, use the usenet for what it's best suited to do. It will pay off for you.
(I have only been using JDBC for a few months and am not the world's premier expert on Java and databases so if it's not in this FAQ I probably only have a guess as to what the answer would be anyway.)
Or, from <http://java.sun.com/products/jdk/1.1/docs/guide/jdbc/index.html>:
Java Database Connectivity is a
standard SQL database access interface, providing uniform access to a wide
range of
relational databases. It also
provides a common base on which higher level tools and interfaces can be
built. This comes
with an "ODBC Bridge". The Bridge
is a library which implements JDBC in terms of the ODBC standard C API.
Another way of saying this is, JDBC specifies an API for database drivers, and for your programs so they can use those database drivers. This means that for 5 different database products, if you can find a JDBC driver for each one, all of them work the same way, at least as far as making connections and executing queries and reading results, even though the SQL syntax you use for each given database may differ a bit.
This is a good thing for many reasons. Mainly, Java is all about interoperability, so the more you can insulate your Java programs (and your own expertise) from being tied to one vendor and one database, the better. Specficially:
There are four types of JDBC drivers, distinguished by how much their implementation depends on platform-native "glue". This distinction is described well at <http://java.sun.com/products/jdk/1.1/docs/guide/jdbc/getstart/intro.doc.html#1005870>.
The distinction is now clear between the four types, but which one do you pick? In most cases, shoot for a Type 4 driver. All you do is add a .zip or .jar file to your classpath and you're done. (Sometimes the vendor adds some license management stuff but that's just another .class file.)
Some have argued that a Type 2 driver is the right choice because it is faster (because of its native implementation), and this may be true. However, in my experience the real-time overhead of a database query has very little to do with the driver and much more to do with things like establishing a TCP/IP connection and authenticating with the database, etc. so it shouldn't really matter unless you expect to be getting 10,000 row result sets back. In that case I suggest that there is probably something seriously wrong with your architecture and you might want to re-think it. If you are writing a bulk importer/exporter in Java, be my guest, use a Type 2 driver.
Type 3 usually involves a commercial bridge product running on the database server which uses ODBC or a platform-native driver to connect to the database. Performance usually suffers due to the added tier, and although multitier architecture is usually a good thing, in this case you can't add any intelligence to the added tier, so it's more of a necessary evil. Type 3 drivers are the best choice for distributed Java applications (applets, or applications running in a VM on a different machine) when you can't find a Type 4 driver.
A list of JDBC drivers for many databases can be found here: http://ourworld.compuserve.com/homepages/Ken_North/jdbcvend.htm
Read the documentation if you really want to learn what the precise specs are. I highly recommend Sun's own documentation and tutorials, and O'Reilly books, particularly Java in a Nutshell. They have helped me tremendously.
Jamie Flournoy (jamie@westlake.com)