JDBC專題介紹（2）

2. 3. JDBC必須可以建立在現(xiàn)有的數(shù)據(jù)庫接口上

我們必須能夠保證 JDBC SQL API 能夠建立在普通的SQL API上，尤其是ODBC。這些要求已經(jīng)對這個規(guī)范的一些部分產(chǎn)生了影響，尤其是對傳出參數(shù)(OUT parameter)和大數(shù)據(jù)塊的處理。

2. 4. 必須保證這個接口與JAVA系統(tǒng)的其他部分保持一致

目前對JAVA的積極回應(yīng)已經(jīng)十分熱烈。很大程度上是由于這個語言標準以及標準運行時庫被認為是一致，簡單和強大的。我們將盡我們所能，提供這個Java數(shù)據(jù)庫接口，這個接口將建立在Java內(nèi)核現(xiàn)有的這種風(fēng)格，并且將進一步加強它。

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盡量簡單，至少開始的時候是這樣的。一般來說，我們希望對實現(xiàn)每個特定的任務(wù)只提供一種方案，而避免提供多種方案。如果一些重要的功能遺漏了，那么我們在晚些時候?qū)U充這個API。

2. 6. 盡量保持強的、靜態(tài)的類型

我們希望這個JDBC API保持盡量強的類型檢查，使得盡可能多的類型信息可以靜態(tài)地表達。著使得盡可能多的錯誤可以在編譯的時候被發(fā)現(xiàn)。

由于SQL本身是動態(tài)類型的，所以我們可能會在程序運行的時候遇到類型不能匹配的問題。例如：當一個程序員在希望SELECT返回一個整數(shù)，但是實際返回的是一個字符串“foo”. 但是我們依然希望程序員把他們所希望的類型在編譯的時候就能夠表達清楚，這樣我們可以做盡可能多的靜態(tài)檢查。我們也希望在必要的時候能夠支持動態(tài)類型接口（見第四章）

2. 7. 使普通任務(wù)簡化

我們希望普通的任務(wù)能夠是簡單的，而不一般的工作是可行的。

一個普通任務(wù)是指一個程序員執(zhí)行一個簡單的沒有參數(shù)的SQL語句（例如:SELECT,INSERT,UPDATE,DELETE），然后(例如SELECT)處理返回的具有簡單類型的元組。一個具有傳入?yún)?shù)（IN parameter）的SQL語句也是普通的。

不那么普通但是也是十分重要的情形是當程序員使用有INOUT,OUT參數(shù)的SQL語句。我們也需要支持讀寫幾兆字節(jié)對象的SQL語句，更特別一些的情形包括一個語句返回了多個結(jié)果集合。

我們希望元數(shù)據(jù)(Meatdata)的使用很少的，只是那些熟練的程序員以及開發(fā)工具才需要處理的問題。元數(shù)據(jù)存取函數(shù)以及動態(tài)類型數(shù)據(jù)存取函數(shù)在這個文檔末尾，一般的程序員可以不必關(guān)心這些章節(jié)。

2. 8. 不同的功能讓不同的方法（函數(shù)）來實現(xiàn)（“方法”的原文是：method，這樣翻譯是跟VB的）

一種界面設(shè)計風(fēng)格是使用很少的過程，提供許多作為參數(shù)傳遞的控制標志，這樣它們可以用來影響很大一個范圍內(nèi)的各種行為。來表達不同的功能。這趨向與使用很多的方法，但是每個方法都比較同意理解。

一般來說，Java內(nèi)核類使用不同的方法（method）。這個步驟的主要優(yōu)點是開始學(xué)習(xí)基本界面的程序員可以不必被那些與復(fù)雜功能相關(guān)的參數(shù)所困擾。我們力圖在JDBC接口上也采用相同的策略。一般來說采用不同的方法而不是采用不同的標志和多用途的方法。