1. 介紹
許多開發者和用戶都在尋找Java程序中訪問數據庫的便捷方法。由於Java是一個健壯，安全，易於使用的，易於理解且可以從網絡中自動download ，所以它成為開發數據庫應用的一種良好的語言基礎。
它提供了C,C++,Smalltalk, BASIC, COBOL, and 4GLs的許多優點。許多公司已經開始在Java與DBMS的連接方面做工作。
許多Java應用開發者都希望能夠編寫獨立於特定DBMS的程序，而我們也相信一個獨立於DBMS的接口將使得與各種各樣DBMS連接變得最為便捷，開發更加迅速。所以我們認為定義一個通用的SQL數據庫存取框架，在各種各樣的提供數據庫連接模塊上提供統一的界面是十分有意義的。
這使程序員可以面對單一的數據庫界面，使數據庫無關的Java工具和產品成為可能，使得數據庫連接的開發者可以提供各種各樣的連接方案。我們看到我們定義一個通用低層的，支持基本SQL功能的JavaDataBase Connectivity (JDBC)API的緊迫任務。
幸運的是我們不必從頭設計一個SQL API。我們可以把我們的工作建立在 X/Open SQL CLI (調用層接口)之上(它也是Microsoft"s ODBC 的基礎)。
我們主要任務是定義一個自然的Java接口來與X/Open CLI中定義的基本的抽象層和概念連接。
JDBC API得到數據庫開發廠商，連接開發廠商，ISV,以及應用開發者的支持是十分重要的。我們相信把我們的工作建立在ODBC抽象層的基礎上將JDBC更加容易得到大家的接受。而且從技術上來說，ODBC是我們設計工作的一個良好基礎。
因為ODBC是一個C語言接口，所以ODBC在Java中直接使用不適當。從Java中來調用C代碼在安全性，健壯性，實現的方便，可移植性等等方面有許多不便。它使得Java在這些方面的許多優點得不到發揮。
我們已經在短期裡面實現了一個建立在ODBC上的API。長遠來看，我們可以通過其他方式提供實現。
1. 1. 注意
我們非常感謝在數據庫，數據庫連接和數據庫工具領域的許多早期的工作者。他們為JDBC的早期草案提供了很好的意見和建議。他們的工作對本規范起了不可估量的作用。
2. 目標與哲學
這個部分描述了指引這個API開發的目標以及哲學。
2. 1. SQL 級 API
我們的主要目標是為Java定義一個“調用級”(call-level)的SQL接口。著意味著我們主要的注意力集中在執行原原本本的SQL語句並且取回結果。我們預計高層的API也將被定義，這些可能將建立在基層的接口上。
這些高層接口包括象直接地、透明地把表裡面的數據影射到Java類裡面，用語法樹表示更加通用的查詢，以及Java內嵌的SQL語法。
我們希望大量的應用開發工具將使用我們的API。然而我們也希望程序員能夠使用我們的API，尤其是目前這樣在Java裡沒有任何其他手段(應該是說數據庫訪問手段)的情況下。
2. 2. 遵循SQL
數據庫系統支持各式各樣的SQL語法和語義，它們相互之間在比較高級的功能例如外部連接，內嵌過程等方面並不一致，盡管我們能夠盼望著隨時間的推移這些部分的SQL可以獲得標准化。同時我們采取這樣的態度與立場：
In fact, an application query need not even be SQL,
or it may be a specialized derivative of SQL,
e.g. for document or image querIEs, designed for specific DBMSs.
In order to pass JDBC compliance tests and to be called
"JDBC COMPLIANT " we require that a driver support at
least ANSI SQL-2 Entry Level. This gives applications
that want wide portability a guaranteed least common
denominator. We belIEve ANSI SQL-2 Entry Level is reasonably
powerful and is reasonably widely supported today.
* JDBC允許查詢表達式直接傳遞到底層的數據驅動，這樣一個程序可以獲得盡量多的SQL功能，但是可能被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”。但是我們依然希望程序員把他們所希望的類型在編譯的時候就能夠表達清楚，這樣我們可以做盡可能多的靜態檢查。我們也希望在必要的時候能夠支持動態類型接口（見第四章）
