转帖自 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本机驱动程序提供的附加工具，这些工具可能会对你的开发工作产生重要影响。