轉帖自 http://cwjt84.spaces.live.com/blog/cns!ff2e198b797a902a!443.entry
JDBC提供了完成下列基本任務的方法：
- 以URL或注冊到JNDI名稱服務的DataSource對象為基礎，建立和管理資料源連接配接。是以，用戶端不必進行複雜的配置。
- 構造SQL指令，向資料源發送SQL指令。
- 提取和處理傳回給Java應用或Applet的結果集。
JDBC規範：
- JDBC 1.0：提供基本的功能，強調易用性。
- JDBC 2.0：提供更多進階功能以及伺服器端的處理能力。
- JDBC3.0：完善了API，優化性能。改進了連接配接池、語句緩沖機制，提供了向Sun連接配接器體系的遷移途徑。
一些在JDBC 2.0規範中可選的功能，例如分布式事務，在JDBC3.0規範中是必需的。同時，JDBC3.0還定義了一些新的特性，例如在緩沖池中緩沖經過預處理的指令等。
最初的Java語言規範并沒有規定Java程式如何通路資料庫。但不久之後，Sun和它的合作者就開始填補這個空白。早期的Java資料通路政策依賴于建立通向ODBC（ODBC是Microsoft發起的資料源通路标準）的橋梁，結果就是JDBC-ODBC橋接驅動程式。
JDBC驅動程式總共有四種類型：
第一類：JDBC-ODBC橋，再加上ODBC驅動程式。
第二類：本機API，部分是Java的驅動程式。
第三類：面向資料庫中間件的純Java驅動程式。
第四類：直接面向資料庫的純Java驅動程式。
第三、四兩類都是純Java的驅動程式，是以，對于Java開發者來說，它們在性能、可移植性、功能等方面都有優勢。
第一類
第一類JDBC驅動程式是JDBC-ODBC橋再加上一個ODBC驅動程式。Sun建議第一類驅動程式隻用于原型開發，而不要用于正式的運作環境。橋接驅動程式由Sun提供，它的目标是支援傳統的資料庫系統。Sun為該軟體提供關鍵問題的更新檔，但不為該軟體的最終使用者提供支援。一般地，橋接驅動程式用于已經在ODBC技術上投資的情形，例如已經投資了Windows應用伺服器。
盡管Sun提供了JDBC-ODBC橋接驅動程式，但由于ODBC會在用戶端裝載二進制代碼和資料庫用戶端代碼，這種技術不适用于高事務性的環境。另外，第一類JDBC驅動程式不支援完整的Java指令集，而是局限于ODBC驅動程式的功能。
第二類
第二類JDBC驅動程式是本機API的部分Java代碼的驅動程式，用于把JDBC調用轉換成主流資料庫API的本機調用。這類驅動程式也存在與第一類驅動程式一樣的性能問題，即用戶端載入二進制代碼的問題，而且它們被綁定了特定的平台。
第二類驅動程式要求編寫面向特定平台的代碼，這對于任何Java開發者來說恐怕都不屬于真正樂意做的事情。主流的資料庫廠商，例如Oracle和IBM，都為它們的企業資料庫平台提供了第二類驅動程式，使用這些驅動程式的開發者必須及時跟進不同資料庫廠商針對不同作業系統發行的各個驅動程式版本。
另外，由于第二類驅動程式沒有使用純Java的API，把Java應用連接配接到資料源時，往往必須執行一些額外的配置工作。很多時候，第二類驅動程式不能在體系結構上與大型主機的資料源相容；即使做到了相容，效果也是差強人意。
由于諸如此類的原因，大多數Java資料庫開發者選擇第三類驅動程式，或者選擇更靈活的第四類純Java新式驅動程式。
第三類
第三類JDBC驅動程式是面向資料庫中間件的純Java驅動程式，JDBC調用被轉換成一種中間件廠商的協定，中間件再把這些調用轉換到資料庫API。第三類JDBC驅動程式的優點是它以伺服器為基礎，也就是不再需要用戶端的本機代碼，這使第三類驅動程式要比第一、二兩類快。另外，開發者還可以利用單一的驅動程式連接配接到多種資料庫。
第四類
第四類JDBC驅動程式是直接面向資料庫的純Java驅動程式，即所謂的“瘦”（thin）驅動程式，它把JDBC調用轉換成某種直接可被DBMS使用的網絡協定，這樣，客戶機和應用伺服器可以直接調用DBMS伺服器。對于第四類驅動程式，不同DBMS的驅動程式不同。是以，在一個異構計算環境中，驅動程式的數量可能會比較多。但是，由于第四類驅動程式具有較高的性能，能夠直接通路DBMS，是以這一問題就不那麼突出了。
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
轉帖自 http://www.examda.com/Java/jichu/20090511/095030298.html
資料庫驅動程式主要有四個類型。
類型一：廠商提供專屬JDBC驅動程式
有些廠商如Oracle或者SYBASE，這些資料庫廠商他們自己開發了一些JDBC驅動程式。這個類型的JDBC驅動程式會将JDBC調用直接轉換為關系資料庫本身使用的通信協定。換一句話說，應用程式用戶端可以直接與資料庫建立連接配接。這種類型的JDBC驅動程式主要有如下幾個特點。
一是JDBC驅動程式是資料庫廠商提供的，是以應用程式可以直接跟資料庫進行連接配接，其執行性能要比其他類型的JDBC資料庫驅動程式要好，比ODBC資料庫驅動程式也要好。目前已經有很多資料庫廠商提供專屬的JDBC驅動程式，如甲骨文公司的Oracle資料庫産品，如微軟公司的SQL Server等等。
二是往往這類JDBC驅動程式全部是由JAVA程式開發的，而不是有C語言開發的。為此這類驅動程式往往跨平台的性能比較好，可以在多個作業系統平台上運作。為此如果企業在Linux等非微軟的作業系統上部署資料庫應用，那麼采用這種類型的資料庫驅動程式是一個明智的選擇。
三是這類驅動程式缺乏彈性。由于是資料庫廠商自己提供的專屬驅動程式，為此往往隻适用于自己的資料庫系統，甚至隻适合某個版本的資料庫系統。如果背景資料庫換了一個或者版本更新了，則就有可能需要更換資料庫驅動程式。這一個缺陷，是限制這個類型的資料庫驅動程式應用的最大障礙之一。不過根據筆者的經驗，如果企業的資料庫應用主要是在企業區域網路内部使用，則這個問題不會很大。因為此時企業往往不會随意更換資料庫系統，或者對資料庫系統進行更新。為此也就會不會因為這個資料庫驅動程式彈性不好而給日後的工作帶來麻煩。
為此筆者建議，如果企業的資料庫應用相對穩定，那麼在資料庫開發或者部署的時候，最好使用廠商提供的專屬JDBC驅動程式。因為這個類型的資料庫驅動程式其與資料庫之間的連接配接最直接，其執行性能最好。不過其前提是資料庫廠商提供了這種類型的JDBC驅動程式。據筆者了解，像開源的MySQL資料庫好像還沒有提供專屬的JDBC驅動程式。如果資料庫管理者在MySQL資料庫平台上部署應用的話，則即使想采用專屬JDBC資料庫驅動程式也是行不通的。此時可能管理者要采用其他類型的JDBC資料庫驅動程式。
類型二：三層式架構的JDBC驅動程式。
這種三層式架構的JDBC驅動程式主要采用間接連接配接方式來連接配接資料庫。首先JDBC資料庫驅動程式會先将JDBC函數調用翻譯成與資料庫無關的網絡通信協定。其次由一個叫做中介層伺服器的部件會充當翻譯家的角色，會對這些封包進行翻譯。最後JDBC才把這部分内容轉換成相對應的關系型資料庫通信協定。也就是說，在用戶端與資料庫伺服器之間有一個中介伺服器的角色，用戶端與伺服器之間的通信需要通過這個中介伺服器來進行。
這個類型的JDBC資料庫驅動類型有如下幾個特點。
一是提供了比較好的擴充性。如當某些原因下需要更換背景資料庫的時候，隻需要調整中介層與資料庫之間的JDBC驅動程式即可。而對于前端的應用程式的負面影響可以降至到最低。在大部分情況下，前端的應用程式基本上不需要調整;有些隻需要重新指定所采用的背景資料庫即可。
二是這個JDBC驅動程式也是百分之百利用JAVA語言進行編寫的。為此如果采用的應用程式開發平台也是JAVA的話，那麼無疑他們之間的相容性會很好。是以如果采用的是JDeveloper等JAVA開發平台的話，這種類型的資料庫驅動程式能夠為資料庫開發人員提供比較穩定的開發平台。
三是在性能上，其不甚理想。由于采用三層式架構的JDBC資料庫驅動程式，其需要通過中介伺服器角色來通路資料庫。雖然這種架構提供了比較高的擴充性，但是其執行性能的話就受到了影響。在同等條件下，這種類型的資料庫驅動程式其執行性能沒有專屬JDBC驅動程式好。魚與熊掌不能夠兼得，資料庫開發人員需要在性能與擴充性上做出一個艱難的抉擇。
類型三：用戶端函數庫類型的資料庫驅動程式。
通常情況下資料庫軟體會提供一種叫做用戶端函數庫的元件。這種類型的資料庫驅動程式就是建立在這個函數庫之上的。此時系統會先将JDBC調用轉換成資料庫的用戶端函數庫對應的應用程式接口(這個步驟在用戶端上完成)，然後再同資料庫進行連接配接。這種方式跟三層式架構的JDBC驅動程式不同。前者是直接連接配接資料庫的，而後者則是以間接的方式(中間有中介伺服器角色)來連接配接資料庫。對于這種類型的資料庫驅動程式有如下幾個特點。
一是建立于各資料庫特有的用戶端函數庫之上，為此其執行性能比較好。通常情況下各個資料庫廠商會根據自己資料庫軟體的特點，開發用戶端函數庫。他們在開發這個函數庫的同時，本身就考慮到了性能與優化方面的問題。而且，這種類型的資料庫驅動程式又是直接連接配接資料庫的，為此從性能上考慮，其要比三層式架構的JDBC驅動程式要好的多。但是反過來說，其執行性能在同等條件下仍然趕不上第一種專屬JDBC驅動程式。
二是其相容性差。如果資料庫管理者采用這個類型的資料庫驅動程式的話，需要在用戶端上安裝特定的軟體(其中包含有用戶端函數庫)。而且這個軟體往往是資料庫廠商提供的。不同廠商的資料庫軟體其用戶端函數庫是不同的。為此如果需要更換資料庫系統的話，此時需要同時更新各個用戶端的函數庫。當資料庫使用者比較多的時候，這是非常耗時的一項工作。
三是其不是百分之百的利用JAVA語言編寫。由于用戶端函數庫中的内容很多都是跟資料庫的程式設計平台相關。為此這種類型的JDBC驅動程式不可能百分之百都有JAVA語言來實作。由于這方面的限制，為此其跟JAVA應用程式開發平台的相容性就沒有以上兩個類型的驅動程式那麼好了。而且能夠提供這種類型的資料庫驅動程式的廠商也不是很多。如好像微軟的SQL SERVER等資料庫系統也沒有提供這方面的JDBC驅動程式。是以從應用層面考慮，這種資料庫驅動類型是使用的最少的。
類型四：橋接型的JDBC驅動程式。
有些應用系統，以前是在ODBC資料庫啟動程式上面開發的;而現在資料庫管理想在JDBC資料庫驅動程式開發應用程式，那該怎麼辦呢?資料庫開發人員是否需要推翻原有的架構進行重新開發呢?答案是否定的，也是肯定的。這個答案或許有點前後沖突的感覺。否定說的是資料庫管理者不用全部推翻原先的架構，而是可以原先的架構跟新的架構并存。肯定的是為了後續應用程式性能與穩定性的考慮，在合适的時候資料庫開發人員最好能夠慢慢的對原先的開發架構進行調整。不過在這個調整的過程中，新舊兩個開發架構是可以同時采用的。另外有些資料庫系統可能沒有提供以上三種類型的任何一種JDBC資料庫啟動程式。如使用使用者比較多的ACCESS資料庫系統。如果JAVA程式開發人員需要在這個資料庫上開發應用軟體的話，可能就需要用到這個橋接型的JDBC驅動程式。這個類型的資料庫驅動程式有如下幾個特點。
一是其保留了ODBC資料庫驅動程式，把相關的SQL語句通過JDBC驅動程式轉換為ODBC資料庫驅動程式可以了解的語句。應用這個資料類型的時候，資料庫管理者不用考慮資料庫底層的連接配接問題。同時如果應用系統原先是在ODBC的架構下開發的，還可以保留原先的架構。
二是其維護比其他類型的驅動程式都要麻煩與複雜。一方面由于這種類型的驅動程式仍然需要用到ODBC，是以在用戶端上還需要部署有ODBC驅動程式。另一方面，系統先調用JDBC驅動程式;然後再通過JDBC驅動程式調用ODBC資料庫驅動程式;然後再連接配接到資料庫。中間經過了多個環節。如何其中任何一個環節出現了問題，都可能導緻資料庫連接配接的故障。萬一真的出現了問題的話，那麼資料庫管理者查找問題就會變得複雜的多。
總之筆者建議資料庫管理者最好采用第一、二種資料庫驅動程式;如果這兩種驅動程式不支援的話，那麼就采用第三種驅動程式。對于第四種驅動程式資料庫管理者要慎用，除非資料庫管理者對自己的能力相當的自信。
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http://yhaiz.blog.163.com/blog/static/7889001120098244316166/
選擇JDBC驅動程式
Sun在http://industry.java.sun.com/products/jdbc/drivers
維護着一個JDBC驅動程式的清單，如圖三所示。這個頁面提供了一個驅動程式選擇工具，能夠根據指定的特征顯示出符合要求的驅動程式，允許指定的特征包括驅動程式類型、支援的JDBC版本、支援的資料庫等等。今天（2002年09月），這個頁面收集的驅動程式已經達到165個！
許多人用這個選擇工具來确定自己要用的驅動程式。是以，有必要詳細介紹一下這個選擇工具：
● JDBC APIVersion：選擇JDBC版本，可從1.x、2.x或3.x中任選一種。
● Certified for J2EE：J2EE認證，可選擇J2EE 1.3或J2EE1.2（其中之一或全部）。
● Driver Type：驅動程式類型，1、2、3或4，任意一種或全部。
● SupportedDBMS：支援的DBMS，有83個選項，大部分是各廠商的資料庫産品，但也有一部分是産業标準，例如JDBC、LDAP、ODBC、OLEDB Provider、Text（TSV）、SQL/DS，以及XML。可選擇一個或多個。
● Required Features：必需的特性，包括DataSource、連接配接池（Conn.Pooling）、分布式事務（Dist.Trans.）、記錄集（RowSets），可任選一個或者多個。
● Returns per page：每頁傳回的結果數量。
圖三：Sun的JDBC驅動程式選擇工具
下面我們來看看各個選項分别有哪些意義。
JDBC API
JDBCAPI的重要性在于，它決定了Java開發者可用的功能。早期的Java應用可能無法使用JDBC3.0提供的許多進階特性，但這些特性對于高事務性、分布式的應用來說必不可少。使用最新版本的JDBCAPI，開發者才能使用各種新的DBMS和作業系統安全擴充，以及諸如連接配接池、語句緩沖池、RowSets對象等最新的性能優化機制。
J2EE認證
記住，JDBC隻是一個規範，而不是一個軟體的标準實作。各個廠商可以根據需要實作自己的JDBC驅動程式。有一些驅動程式完全遵從J2EE規範，還有許多驅動程式不遵從J2EE規範。JDBC驅動程式的J2EE認證（即擷取Certifiedfor J2EE logo）由Sun的CTS（Certification TestSuite）确定，如果要判斷一種驅動程式是否比另一種優秀，它可以作為判斷驅動程式品質的标準之一。一般我們可以認為，通過這種認證的廠商對産品品質比較關注，在http://java.sun.com/products/jdbc/industry.html可以找到一個擁有相關産品且認可（Endorse）JDBC标準的廠商清單。
必需的特性
圖三RequiredFeatures部分提供了幾個JDBC驅動程式的特性選項，這些特性在JDBC2.0規範中開始引入，但在JDBC 3.0中是必需的。
DataSource是一個由JDBC驅動程式管理的包含資料庫連接配接資訊的對象。DataSource與JNDI服務協作，資料庫連接配接的執行個體化和管理工作都獨立于使用它的應用之外。與連接配接有關的資訊，例如路徑和端口号，可以在DataSource對象的屬性中友善地修改，無需改動使用該資料源的應用代碼。目前，Sun收集的總共165個驅動程式中有62個支援該特性。
JDBC支援連接配接池。所謂連接配接池，就是讓一些資料庫連接配接對象在緩沖池中保持打開狀态，使得任何請求使用資料庫連接配接的應用都能夠立即獲得資料庫連接配接，不再需要昂貴的網絡開銷聯系資料庫伺服器取得連接配接，連接配接池會從本地緩沖池中取得空閑的連接配接賦予送出請求的Java應用。當應用終止資料庫連接配接，資料庫連接配接實際上并未被拆除，而是傳回給連接配接池緩沖區供其他應用重用，進而有效地提升資料庫通路性能。
在資料庫事務中，建立連接配接是資源開銷最大的操作。當一個應用試圖建立資料庫連接配接時，需要多次網絡互動過程才能完成（例如，對于Oracle資料庫連接配接，這個數字是9）。然而，一旦成功建立了連接配接，把這個連接配接保留下來再在以後的操作中重用，開銷就要小得多。資料庫連接配接池特性大大提高了改進資料傳輸性能和可伸縮性的潛力，對于應用伺服器來說尤其如此。Sun收集的JDBC驅動程式中有62個支援連接配接池。
在分布式系統中，應用常常需要用多個事務提取資料，且資料往往來自多個資料源。要求有獨立的事務協調系統進行協調的事務稱為分布式事務。對于Java資料庫開發者來說，除了JDBC驅動程式的性能名額之外，分布式事務支援也許是最重要的特性了。
分布式事務要求有額外的資源提供可靠的支援，這主要是由于從不同資料源提取資料的延遲不同，同時也由于存在着互操作的問題。例如，要區分一個失敗的事務和一個響應緩慢的事務并不容易，這就要求DTS中的資料總管以适當的方式注冊并協調ROLLBACK或COMMIT操作，同時應當盡量地減少程式設計工作量。
一般地，分布式事務利用事務管理器（TransactionManager）進行不同資料總管的協調工作。有了DTP（DistributedTransactionProcessing）體系中的事務管理器提供應用與資源的仲裁，就有可能為應用提供跨越多個資料資源的ACID事務。
在需要多個步驟才能得出所需結果的場合，需要有一種軟體子產品，通常是事務管理器，協調各個處理過程，例如iPlanetTrustbase TransactionManager就是這樣一個産品。目前Sun收集的JDBC驅動程式中有45個支援此特性。
RowSets（記錄集）對象是查詢的結果集，包含從表格式資料源擷取的記錄。RowSets擁有類似于JavaBean的屬性和事件提醒機制，同時它本身也是一個JavaBean元件，可以在開發環境中用程式設計的方式建立和使用。RowSets有連接配接的（Connected）和非連接配接的（Disconnected，或稱之為離線式的）兩種類型。非連接配接的記錄集在提取資料時需要連接配接到資料源，但處于非連接配接狀态時就不再需要JDBC驅動程式。這種記錄集體積小，常用來把資料發送給瘦用戶端。非連接配接的記錄集儲存在記憶體中，同時儲存的還有其原資料（Metadata）和連接配接以及執行指令。與此相對，連接配接的記錄集在被使用時總是保持一個打開的連接配接。目前Sun收集的驅動程式共有31個支援記錄集特性，這個數字相對較小，也許是由于該特性不是經常要用到。
必須指出的是，Sun的JDBC網站把“支援”RowSets定義成JDBC驅動程式本身正式打包和帶有RowSets，是以，這個網站上列出的一些驅動程式可能沒有支援RowSets的标記，但它們實際上卻支援多種RowSets。
JDBC 3.0規範定義了prepared statementpooling（把已準備好的SQL語句放入緩沖池），目前未被Sun加入到圖三的JDBC驅動程式搜尋工具，但可以确信它不久就會被作為一個可搜尋的特性加入。從本質上看，語句緩沖是把已經優化且已經運作過的SQL語句儲存到緩沖池，一旦需要再次執行，可以不必再進行優化之類的預處理過程。SQL語句池能夠顯著地提升性能，對于任何JDBC驅動程式來說，它都是一個值得關注的亮點。
對于需要多次執行的SQL語句，緩沖已準備好的語句特别有用。舉例來說，如果一個查詢的功能是提取特定産品類别的目前庫存值，每天都要頻繁地運作多次，那麼它就可以從語句緩沖獲益。再次執行已緩沖的SQL語句時，隻需向查詢傳入參數；所有的預處理步驟，例如文法檢查、目标合法性檢查、優化通路路徑、優化執行計劃等，都已經緩沖在記憶體中。
對于開發者來說，語句緩沖池還有一個特别的優點，即它無需開發者編寫任何代碼（就如連接配接池一樣）。隻要你采用了帶有語句池機制的驅動程式，你就得到了語句緩沖帶來的性能優勢。
隻要JDBC驅動程式支援，語句池和連接配接池可以在一個應用中同時起作用。當程式用到來自連接配接池的連接配接，所有以前曾經運作過SQL語句的連接配接會擁有已經定義好的語句池。是以，即使應用第一次利用某個連接配接準備執行SQL語句，也可能不需要SQL語句執行前的準備過程。
結束語
JDBC驅動程式會對應用的表現産生許多重大的影響。對于系統的整體性能來說，JDBC驅動程式的特性實際上是一個關鍵性因素。不僅在企業級資料庫應用中是這樣，對于要通路分布式資料資源的應用，這個問題就更加突出。
從長遠的眼光來看，當你選擇驅動程式時，請把JDBC3.0定義的特性，包括DataSource對象、連接配接池、分布式事務支援、RowSets、語句緩沖池等，作為選擇标準之一。隻要有可能，就要選擇那些直接操作資料庫API的驅動程式，而不要選擇那些經過一層轉換後才與資料庫API互動的驅動程式，因為前者往往具有較好的性能表現。
如果性能和對Java标準的遵從性都是必不可少的考慮因素，驅動程式非三、四兩類莫屬。找出那些支援最新版本規範、提供最豐富功能的JDBC驅動程式，絕對是一件值得做的事情。另外還有一個需要考慮的因素是，個别JDBC驅動程式提供了一些通常不會随着DBMS本機驅動程式提供的附加工具，這些工具可能會對你的開發工作産生重要影響。