附录 D：SQL3 建议书的促动因素

以下意见和要求决定了本建议书的基本内容：

• Java 程序将 SQL 类型的数值作为单个 Java 数据项来进行检索。例如，在 Java 中可以只通过一次方法调用（例如调用 getObject() 方法）将结构化 SQL 类型的实例作为单个对象来实现。
  
  
• Java 程序将 SQL 值作为“强类型的”Java 对象来进行检索。例如，在 Java 中可以将结构化类型实例作为具有域或方法（这里的域或方法对应于该特定结构化类型的属性，而且允许程序访问结构化类型的属性）的类的对象来实现。
  
  
• 客户机端 Java 应用程序可以从“不知道 Java” 的数据库中检索用户定义的 SQL 类型的值。该数据库中不需要提供 Java 支持。例如，在数据库中不必作特殊的定义以允许 Java 程序检索结构化类型数据。
  
  
• 特别值得注意的是，结构化类型数据数值是利用 SELECT 语句检索到 Java 中的；而且是通过 INSERT 和 UPDATE 语句传递到数据库中的；诸如此类。
  
  
• 结构化类型的 SQL 方法将在服务器中执行，它与将结构化类型数据从 SQL 检索到 Java 程序这件事无关。
  
  
• 在 SQL 目录表中用户自定义 SQL 类型的定义是可见的。同样，可以通过射像 API 利用编程途径获得 Java 类的定义。因此，数据库工具厂商可以编写为 SQL 数据生成 Java 定义的工具（反之亦然），而这与关系数据库厂商无关。我们所采用的从 SQL 类型到 Java 的映射方式必须允许第三方编写这样的工具。
  
  
• 我们假设 SQL 用户自定义类型和任何 Java 类之间的映射方式通常由工具生成。没有必要设计映射方式，这样程序设计人员可以轻易地“手写”映射方式。
  
  
• 没有理由只将一种从 SQL 类型到某类的映射方式定义为唯一“正确的”映射方式。映射工具对给定的 SQL 用户自定义类型可以定义不同的 Java 类，以满足不同应用范围或执行环境的需要。这些不同的类对应于基本属性可以有不同的映射方式，而且对于不同的应用程序还可以有相关的辅助域。我们所采用的从 SQL 用户自定义类型到 Java 的映射方式应该允许这样的变化。
  
  
• 我们想要支持这样的 Java 程序：以“动态 SQL”的方式取回 SQL 用户自定义类型的数据，而不必事先“知道”这些数据的属性的数目和种类。
  
  
• SQL 结构化类型可以包含 REF（结构化类型）类型的属性，REF 类型所引用的行包含有另一个结构化类型实例。尽管具有表面上的相似性，但是 SQL REF 与包含另一个轻型 Java 对象的 Java 域并不相似。SQL REF 是用来指定表中某行的健值；它并不在瞬态存储器中指定对象。
  
  
• 用户通常希望在 SQL 类型和 Java 类之间具有一一对应的映射方式。Java 到 SQL 的映射工具将为每个 distinct 类型、每个结构化类型、每个 REF（结构化类型）、每个数组类型、每个 Locator 类型等生成类。
  
  
• 我们希望在 SQL 类型到 Java 的映射方式中提供一些灵活性，以便于工具开发者和特定于域的“应用服务层”的实现者可以通过自定义实现 SQL 类的 Java 类来添加转换值。特别值得注意的是，从叶 SQL 属性和元素到 Java 域和变量的映射方式允许使用 JDBC 目前所允许的所有转换。可以通过任意方式将 SQL 名称映射到 Java 名称。可以用一个 Java 对象或多个 Java 对象来表示 SQL 值。
  
  

目录 | 上一页 | 下一页

版权所有 © 1996, 1997 Sun Microsystems, Inc. 保留所有权利。