JDBC專題介紹（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接口上也采用相同的策略。一般來說采用不同的方法而不是采用不同的標志和多用途的方法。