Java can be used to access many kinds of databases. A database can be something as simple as a text file or a fast key/value pairing on disk (DBM format), as sophisticated as a relational database management system (DBMS), or as exotic as an object database.

Regardless of how your data is actually stored, in a reasonable application you’ll want to write a class called an accessor to mediate between the database and the rest of the application. For example, if you are using JDBC, the answers to your query will come back packaged in an object called a ResultSet, but it would not make sense to structure the rest of your application around the ResultSet because it’s JDBC-specific. In a Personal Information Manager application, for example, the primary classes might be Person, Address, and Meeting. You would probably write a PersonAccessor class to request the names and addresses from the database (probably using JDBC), and generate Person and Address objects from them. The DataAccessor objects would also take updates from the main program and store them into the database.^[46]

Java DataBase Connectivity (JDBC) consists of classes in package java.sql and some JDBC Level 2 extensions in package javax.sql. (SQL is the Standard Query Language, used by relational database software to provide a standard command language for creating, modifying, updating, and querying relational databases.)

Why was JDBC invented? Java is highly portable, but many databases previously lacked a portable interface and were tied to one particular language or platform. JDBC is designed to fill that gap.

JDBC is patterned very loosely on Microsoft’s Open DataBase Connectivity (ODBC). Sun’s Java group borrowed several general ideas from Microsoft, who in turn borrowed some of it from prior art in relational databases. While ODBC is C- and pointer-based (void * at that), JDBC is based on Java and is therefore portable, as well as being network-aware and having better type checking.

JDBC comes in two parts: the portable JDBC API provided with Java, and the database-specific driver usually provided by the DBMS vendor or a third party. These drivers have to conform to a particular interface (called Driver, unsurprisingly) and map from the generic calls into something the existing database code can understand.

JDBC deals with relational databases only. No flat files (although several drivers have been written that map from flat files to the JDBC API) and no DBM files (though you could write a driver that used one DBM file for each table in a database). Through this clever division of labor, JDBC can provide access to any relational database, be it local or remote (remote databases are accessed using client sockets, as discussed in Chapter 15). In addition to the drivers from database vendors, there is also a JDBC-ODBC bridge in the standard JDK and JRE; this allows you to use JDBC with an existing MS-Windows database. Its performance is weaker because it adds an extra layer, but it does work.

One fairly common form of database that I do not cover is the so-called Xbase format, which is a series of commercial databases (dBase, FoxBase, etc.) common in the MS-DOS and MS-Windows world. If you wanted to decode such a database in Java, you’d probably start with the Xbase file format, documented at http://www.e-bachmann.dk/docs/xbase.htm. Alternately, you might find a useful driver in the Microsoft ODBC-32 software, and use the JDBC-to-ODBC bridge to convert your data to a newer format such as a relational database.

This chapter is an overview of several database techniques, emphasizing JDBC, so that you know what this technology looks and feels like.