JDK 5 Documentation v1.2.2, Java 2 SDK 英文文档

Contents | Prev | Next

JDBC^TM Guide: Getting Started

Appendix D: Motivation for the SQL3 Proposal

The following observations and requirements have shaped this proposal:

A Java program will retrieve a value of an SQL type as a single Java data item. For example, an instance of a structured SQL type can be materialized in Java as a single object, by a single method call (e.g., to method getObject()).
A Java program will retrieve an SQL value as a "strongly typed" Java object. For example, a structured type instance will be materialized in Java as an object of a class with fields or methods that correspond to the attributes of that particular structured type, and that allow the program to access the attributes of the structured type.
A client-side Java program can retrieve values of user-defined SQL types from a database that is "unaware" of Java. No Java support is required in that database. For example, no special definitions must be made in the database to allow structured type data to be retrieved by Java programs.
In particular, structured type values are retrieved into Java by means of SELECT statements; are posted to the database by INSERT and UPDATE statements; and so on.
The SQL methods of a structured type execute in the server, and are not relevant to the issue of retrieving structured type data from SQL into Java programs.
Definitions of user-defined SQL types are visible in SQL catalog tables. Similarly, definitions of Java classes are programmatically available thru the reflection API. Therefore, tools that generate Java definitions for SQL data, or vice versa, can be written by database tools vendors, independent of any particular relational database vendor. Our mappings of SQL types to Java must permit third-parties to write such tools.
We assume that the mappings between SQL user-defined types any Java classes will usually be generated by tools. It is not necessary to design the mappings so that human programmers can easily write them "by hand".
There is no reason to define exactly one mapping of an SQL type to a class as the only "correct" mapping. Mapping tools may define different Java classes, corresponding to a given SQL user-defined type, to serve different application domains or execution environments. Such different classes may have different type mappings for the primitive attributes, or auxilliary fields that are relevant to a particular application. Our mappings of SQL user-defined types to Java should allow such variations.
We want to support Java programs that fetch data of SQL user-defined types in a "dynamic SQL" style, without "knowing" in advance the number and kinds of attributes of those data.
An SQL structured type may contain an attribute of a REF(structured-type) type that references a row containing another structured type instance. Despite a superficial similarity, that SQL REF is not analogous to a Java field containing another lightweight Java object. An SQL REF is a key value that designates a row of a table; it does not designate an object in transient memory.
Users will often want a 1-1 mapping between SQL types and Java classes. Java- to-SQL mapping tools will generate a class for each distinct type, for each structured type, for each REF(structured-type), for each array type, for each Locator type, and so on.
We want to allow flexibility in the mappings of SQL types to Java, so that tools builders, and implementers of domain-specific "application service layers" can add value by customizing the Java classes that implement SQL types. In particular, the mapping of leaf SQL attributes and elements to Java fields and variables permits all conversions that JDBC currently permits. SQL names may be mapped to Java names in arbitrary ways. An SQL value may be represented by one Java object, or by a graph of Java objects.

Contents | Prev | Next

jdbc@eng.sun.com or jdbc-business@eng.sun.com