JDBC专题介绍
功能，但是可能被DBMS拒绝。事实上，一个程序的查询甚至可以不是SQL的，或者是SQL的一个特殊演化，例如：为专门数据库设计的文本或者图形查询。
* 为了通过JDBC兼容的测试，并且能够被称为JDBC兼容，我们要求一个驱动至少支持ANSI SQL-2的标准。这使得那些需要广泛移植性的程序获得一个最小的分母(这句话的原文是：This gives applications that want wide portability a guaranteed least common denominator.)。我们相信ANSI SQL-2是足够强大的，并且是得到足够支持的。
2. 3. JDBC必须可以建立在现有的数据库接口上
我们必须能够保证 JDBC SQL API 能够建立在普通的SQL API上，尤其是ODBC。这些要求已经对这个规范的一些部分产生了影响，尤其是对传出参数(OUT parameter)和大数据块的处理。
2. 4. 必须保证这个接口与JAVA系统的其他部分保持一致
目前对JAVA的积极回应已经十分热烈。很大程度上是由于这个语言标准以及标准运行时库被认为是一致，简单和强大的。我们将尽我们所能，提供这个Java数据库接口，这个接口将建立在Java内核现有的这种风格，并且将进一步加强它。
2. 5. 保持简单
We would prefer to keep this base API as simple as possible, at least initially. In general we would prefer to provide a single mechanism for performing a particular task, and avoid provid-ing duplicate mechanisms. We will extend the API later if any important functionality is miss-ing.
我们将力争使得基本的API尽量简单，至少开始的时候是这样的。一般来说，我们希望对实现每个特定的任务只提供一种方案，而避免提供多种方案。如果一些重要的功能遗漏了，那么我们在晚些时候将扩充这个API。
2. 6. 尽量保持强的、静态的类型
我们希望这个JDBC API保持尽量强的类型检查，使得尽可能多的类型信息可以静态地表达。着使得尽可能多的错误可以在编译的时候被发现。
由于SQL本身是动态类型的，所以我们可能会在程序运行的时候遇到类型不能匹配的问题。例如：当一个程序员在希望SELECT返回一个整数，但是实际返回的是一个字符串“foo”. 但是我们依然希望程序员把他们所希望的类型在编译的时候就能够表达清楚，这样我们可以做尽可能多的静态检查。我们也希望在必要的时候能够支持动态类型接口（见第四章）
2. 7. 使普通任务简化
我们希望普通的任务能够是简单的，而不一般的工作是可行的。
一个普通任务是指一个程序员执行一个简单的没有参数的SQL语句（例如:SELECT,INSERT,UPDATE,DELETE），然后(例如SELECT)处理返回的具有简单类型的元组。一个具有传入参数（IN parameter）的SQL语句也是普通的。
不那么普通但是也是十分重要的情形是当程序员使用有INOUT,OUT参数的SQL语句。我们也需要支持读写几兆字节对象的SQL语句，更特别一些的情形包括一个语句返回了多个结果集合。
我们希望元数据(Meatdata)的使用很少的，只是那些熟练的程序员以及开发工具才需要处理的问题。元数据存取函数以及动态类型数据存取函数在这个文档末尾，一般的程序员可以不必关心这些章节。
2. 8. 不同的功能让不同的方法（函数）来实现（“方法”的原文是：method，这样翻译是跟VB的）
一种界面设计风格是使用很少的过程，提供许多作为参数传递的控制标志，这样它们可以用来影响很大一个范围内的各种行为。来表达不同的功能。这趋向与使用很多的方法，但是每个方法都比较同意理解。
一般来说，Java内核类使用不同的方法（method）。这个步骤的主要优点是开始学习基本界面的程序员可以不必被那些与复杂功能相关的参数所困扰。我们力图在JDBC接口上也采用相同的策略。一般来说采用不同的方法而
* 为了通过JDBC兼容的测试，并且能够被称为JDBC兼容，我们要求一个驱动至少支持ANSI SQL-2的标准。这使得那些需要广泛移植性的程序获得一个最小的分母(这句话的原文是：This gives applications that want wide portability a guaranteed least common denominator.)。我们相信ANSI SQL-2是足够强大的，并且是得到足够支持的。
2. 3. JDBC必须可以建立在现有的数据库接口上
我们必须能够保证 JDBC SQL API 能够建立在普通的SQL API上，尤其是ODBC。这些要求已经对这个规范的一些部分产生了影响，尤其是对传出参数(OUT parameter)和大数据块的处理。
2. 4. 必须保证这个接口与JAVA系统的其他部分保持一致
目前对JAVA的积极回应已经十分热烈。很大程度上是由于这个语言标准以及标准运行时库被认为是一致，简单和强大的。我们将尽我们所能，提供这个Java数据库接口，这个接口将建立在Java内核现有的这种风格，并且将进一步加强它。
2. 5. 保持简单
We would prefer to keep this base API as simple as possible, at least initially. In general we would prefer to provide a single mechanism for performing a particular task, and avoid provid-ing duplicate mechanisms. We will extend the API later if any important functionality is miss-ing.
我们将力争使得基本的API尽量简单，至少开始的时候是这样的。一般来说，我们希望对实现每个特定的任务只提供一种方案，而避免提供多种方案。如果一些重要的功能遗漏了，那么我们在晚些时候将扩充这个API。
2. 6. 尽量保持强的、静态的类型
我们希望这个JDBC API保持尽量强的类型检查，使得尽可能多的类型信息可以静态地表达。着使得尽可能多的错误可以在编译的时候被发现。
由于SQL本身是动态类型的，所以我们可能会在程序运行的时候遇到类型不能匹配的问题。例如：当一个程序员在希望SELECT返回一个整数，但是实际返回的是一个字符串“foo”. 但是我们依然希望程序员把他们所希望的类型在编译的时候就能够表达清楚，这样我们可以做尽可能多的静态检查。我们也希望在必要的时候能够支持动态类型接口（见第四章）
2. 7. 使普通任务简化
我们希望普通的任务能够是简单的，而不一般的工作是可行的。
一个普通任务是指一个程序员执行一个简单的没有参数的SQL语句（例如:SELECT,INSERT,UPDATE,DELETE），然后(例如SELECT)处理返回的具有简单类型的元组。一个具有传入参数（IN parameter）的SQL语句也是普通的。
不那么普通但是也是十分重要的情形是当程序员使用有INOUT,OUT参数的SQL语句。我们也需要支持读写几兆字节对象的SQL语句，更特别一些的情形包括一个语句返回了多个结果集合。
我们希望元数据(Meatdata)的使用很少的，只是那些熟练的程序员以及开发工具才需要处理的问题。元数据存取函数以及动态类型数据存取函数在这个文档末尾，一般的程序员可以不必关心这些章节。
2. 8. 不同的功能让不同的方法（函数）来实现（“方法”的原文是：method，这样翻译是跟VB的）
一种界面设计风格是使用很少的过程，提供许多作为参数传递的控制标志，这样它们可以用来影响很大一个范围内的各种行为。来表达不同的功能。这趋向与使用很多的方法，但是每个方法都比较同意理解。
一般来说，Java内核类使用不同的方法（method）。这个步骤的主要优点是开始学习基本界面的程序员可以不必被那些与复杂功能相关的参数所困扰。我们力图在JDBC接口上也采用相同的策略。一般来说采用不同的方法而