动,上面提到的 industry.java.sun/products/jdbc/drivers DataDirect 公司 datadirect-technologies/jdbc/jdbc.asp 就提供了支持 MS SQL (datadirect- technologies/jdbc/jdbc.asp) datadirect es/jdbc/jdbc.asp 的模式 4 驱动,只是你需要支付 750$购买这个 JDBC 驱动。 同样是纯
Java 实现的模式 3,与模式 4 相比,优势在于对多种数据库的支持,体现了其灵活性。在 大型的企业级的软件应用中,后台数据库往往不是一个,而且是由不同的厂商支持的。不过,模式 3 的 JDBC 驱动往往提供许多企业级的特征,例如 SSL 安全、支持分布式事务处理和集中管理等,因而 会对你特殊的用途有很大的帮助。是否选用,还在于你对扩展应用是否有需求以及对多 DBMS 的支持。 谈到这儿,我对模式 3 和模式 4 作一个总结:两者都是纯 Java 实现的驱动,因而不需要数据库厂商 提供附加的
软件,就可以运行在任何标准的 Java 平台,性能上比较高效、可靠。 了解上述 3 种 JDBC 的实现模式之后,模式 2 就更容易阐释了,你可以理解它为前三者利弊平衡的妥 协产物: 1 借鉴模式 1 利用客户机本地代码库,加速数据访问的执行,但却摒除 ODBC 标准,而是支持厂商自 己指定的性能扩展 借鉴模式 3 利用多层结构,上层用 Java 实现,利于跨平台应用和支持多数据库,但下层却改为本 地代码,加速执行速度
2
3 借鉴模式 4 和数据库结合紧密的优点,部分用 Java 实现
,更是对数据库性能有很大的扩展 这种开放和高性能的特征得到了业界的肯定,因而被主要的数据库厂商强烈推荐。尽管它需要你下载 本地代码库到客户机,但相对于你访问数据库速度的提高,这些应该只是举手之劳了。下面对 4 种实 现 JDBC 的模式选择,归纳一下选择的顺序(当然是指你有选择余地的时候,不存在的话向后推延) : 编 号 1 2 选择过程分析 实验性环境下,尽可能选择易于配置的驱动,利于 Java 程序的开发,后期可在对应 用环境进行判断后,再对 JDBC 模式进行选择 选 择 顺 序 1>2>3>4
小型企业级环境下,不需要对多数据库的支持,因而模式 2 和 3 的有些优点并不能 4>2=3>1
体现出来,强烈推荐你选择模式 4 的 JDBC 驱动 3 大型企业级环境下,需要对多数据库的支持,模式 2 和 3 各有千秋,但是更多情况 下是你会选择速度较快的模式 2 2>3>4>1
对于不同厂商提供的但应用相同模式的 JDBC 接口,理论上比较不出效率的高低,你只有通过一定的 工具,例如 Benchmark 等,对它们进行比较才能更有利于你的选择。因为暂时不存在第三方提供的数 据比较结果,所以这些问题需要你对上述内容有了透彻理解之后自行解决。
Java 程序中 SQL 语句格式的优化
这个时候,你也许还在为找不到合适的 JDBC 驱动而一筹莫展,也许为自己在凌晨 3 点下载的 JDBC 驱 动通过了测试而欣喜若狂,但是并不说明你对程序的优化
工作已经无关紧要了。切记,对整个软件系 统的优化,包括每个环节的优化,要不有可能你会前功尽弃。我在这儿不和大家讨论 Java 程序的算 法,而是简单阐述一下选择 SQL 语句格式的必要和如何选择对自己有利的 SQL 语句格式。看下面两段 程序片断: Code Fragment 1:
String updateString = "UPDATE COFFEES SET SALES = 75 " + "WHERE COF_NAME LIKE 'Colombian'"; stmt.executeUpdate(updateString);
Code Fragment 2:
PreparedStatement updateSales = con.prepareStatement("UPDATE COFFEES SET SALES = ? WHERE COF_NAME LIKE ? "); updateSales.setInt(1, 75); updateSales.setString(2, "Colombian"); updateSales.executeUpdate();
片断 2 和片断 1 的区别在于, 后者使用了 PreparedStatement 对象, 而前者是普通的 Statement 对象。 PreparedStatement 对象不仅包含了 SQL 语句,而且大多数情况下这个语句已经被预编译过,因而当 其执行时,只需 DBMS 运行 SQL 语句,而不必先编译