【正文】 .A Base for Other JDBC API is used to invoke (or call) SQL mands directly. It works very well in this capacity and is easier to use than other database connectivity APIs, but it was also designed to be a base upon which to build alternate interfaces and tools. An alternate interface tries to be userfriendly by using a more understandable or more convenient API that is translated behind the scenes into the JDBC API. Because the JDBC API is plete and powerful enough to be used as a base, it has had various kinds of alternate APIs developed on top of it, including the following: An embedded SQL for Java. A consortium including Oracle, IBM, Sun, and others has defined the SQLJ specification to provide this. JDBC requires that SQL statements basically be passed as uninterpreted strings to Java methods. An embedded SQL preprocessor provides piletime type checking and allows a programmer to intermix SQL statements with Java programming language statements. For example, a Java variable can be used in an SQL statement to receive or provide SQL values. The SQLJ preprocessor effectively translates this Java/SQL mix into the Java programming language with JDBC calls. A direct mapping of relational database tables to Java classes. Java Software has announced the Java Blendtm product to provide this, and others have similar products. In this object/relational mapping, a table bees a class, each row of the table bees an instance of that class, and each column value corresponds to an attribute of that instance. Programmers can then operate directly on Java objects。 the required SQL calls to fetch and store data are automatically generated beneath the covers. Java Blend also allows more sophisticated mappings, for example, where rows of multiple tables are bined in a Java class. As interest in JDBC technology has grown, other JDBCbased tools have been developed to make building programs easier. For example, an application might present a menu of database tasks from which to choose. After a task is selected, the application presents prompts and blanks for filling in information needed to carry out the selected task. With the requested input typed in, the application then automatically invokes the necessary JDBC mands. With the help of such an application, users can perform database tasks even when they have little or no knowledge of SQL syntax. The JDBC API versus ODBC and UDA. Prior to the development of the JDBC API, Microsoft39。s ODBC (Open DataBase Connectivity) API was the most widely used programming interface for accessing relational databases. It offers the ability to connect to almost all databases on almost all platforms. So why not just use ODBC from Java? The answer is that you can use ODBC from Java, but this is best done with the help of the JDBC API in the form of the JDBCODBC Bridge. The question now bees, Why do you need the JDBC API?There are several answers to this question. ODBC is not appropriate for direct use from the Java programming language because it uses a C interface. Calls from Java to native C code have a number of drawbacks in the security, implementation, robustness, and automatic portability of applications. A literal translation of the ODBC C API into a Java API would not be desirable. For example, Java has no pointers (address variables), and ODBC makes copious use of them, including the notoriously errorprone generic pointer void *. You can think of JDBC as ODBC translated into a highlevel objectoriented interface that is natural for programmers using the Java programming language. ODBC is hard to learn. It mixes simple and advanced features together, and it has plex options even for simple queries. The JDBC API, on the other hand, was designed to keep simple things simple while allowing more advanced capabilities where required. The JDBC API is also easier to use simply because it is a Java API, which means that a programmer does not need to worry about either memory management or data byte alignment. A Java API like JDBC is needed in order to enable a pure Java solution, that is, a solution that uses only Java API. When ODBC is used, the ODBC driver manager and drivers must be manually installed on every client machine. When the JDBC driver is written pletely in Java, however, JDBC code is automatically installable, portable, and secure on all Java platforms from network puters to mainframes. In summary, the JDBC API is a natural Java interface for working with SQL. It builds on ODBC rather than starting from scratch, so programmers familiar with ODBC will find it very easy to learn. The JDBC API retains some of the basic design features of ODBC。 in fact, both interfaces are based on the Open Group (formerly X/Open) SQL CLI (Call Level Interface). The big difference is that the JDBC API builds on and reinforces the style and virtues of Java, and it goes beyond just sending SQL statements to a relational database management system. Microsoft has introduced new APIs beyond ODBC such as OLE (Object Linking and Embedding) DB, ADO (ActiveX Data Objects), and RDS (Remote Data Service). In many ways these APIs move in the same direction as the JDBC API. For example, OLE DB and ADO are also objectoriented interfaces to databases that can be used to execute SQL statements. However, OLE DB is a lowlevel interface designed for tools rather than developers. ADO is newer and more like the JDBC API, but it is not pure Java. RDS provides functionality similar to the JDBC API39。s RowSet facility, but RDS is also not written in the Java programming language, and it is not portable. Most recently, Microsoft has introduced UDA (Universal Data Access) as an umbrella term that covers OLE DB, ADO, RDS, and ODBC. The JDBC API contains all of the important functionality of UDA plus features not found in UDA, such as SQL3 support. Twotier and Threetier ModelsThe JDBC API supports both twotier and threetier models for database access.