万维网信息数据获取：RDBMS网关架构解析

### 万维网信息数据获取：RDBMS 网关架构解析 #### 1. API 性能对比 在某些情况下，NSAPI 的性能比 ISAPI 高出 40%；而在其他情况下，NSAPI 能达到 ISAPI 最佳性能的 82%。这些差异归因于 WebStone 基准测试中 NSAPI 代码的特定修改。不过，这两个性能评估测试并未得出明确结果。微软的 IIS（以及 ISAPI）似乎与 Windows 环境更适配，而 NSAPI 是一种可移植规范，能应用于 Netscape 服务器，不受底层操作系统的限制。 #### 2. RDBMS 网关架构的发展 万维网平台的一个重要应用是数据库管理系统（尤其是关系型数据库管理系统，RDBMS）的集成。相关的万维网应用涉及通用架构、有状态操作和性能等诸多问题。 1993 - 1994 年，出现了用于关系管理系统的首批万维网接口。1995 年，Nomad 的 WebDBC、Allaire 的 Cold Fusion 和 Aspect Software Engineering 的 dbWeb 等产品相继问世。这类中间件的重要性推动了相关软件的快速发展，它们已成为互联网和企业内联网的关键组件。第一代 WWW - RDBMS 接口产品主要针对 Windows NT 平台，借助 ODBC 规范访问数据库。 在开发通用 RDBMS 接口的过程中，发现用户查询信息时，大量时间花费在与关系管理系统建立连接上（以基于 CGI 规范的原型为例，使用的是 Informix）。无论采用的网关机制效率如何（如“慢速”的 CGI 与“快速”的服务器 API），每次请求都建立新连接既耗时又耗资源，应尽量减少甚至避免。虽然 CGI 规范在执行速度上效率不高，会影响系统性能，但如果出于可移植性和标准合规性的考虑必须采用，就需要想出“巧妙”的解决方案。 #### 3. 永久连接方案 为解决上述问题，采用了与数据库管理系统建立永久连接的方案。永久连接由一个或多个守护进程在服务主机内建立，这些守护进程代表特定客户端（以及网关实例，如 CGI 脚本）执行查询。守护进程避免了大量数据库连接的低效建立和资源浪费，相关成本由守护进程在实际执行查询前承担，而非网关实例在请求分发时承担，因此用户在查询信息时不会感受到额外的时间开销。该方案的架构如图所示： ```mermaid graph LR A[Any generic database API (interface D)] --> B[:|PMS] B --> C[/HTTP communication (interface A)/] B --> D[/Any gateway specification (interface B)/] B --> E[/Proprietary protocol (interface C)/] D --> F[Same or separate processes] E --> F ``` #### 4. 通用 DBMS 接口 在基于守护进程的架构中，与 DBMS 的接口（接口 D）以及与网关实例的通信机制（接口 C）非常重要。守护进程应能分发任何类型的 SQL 查询，而不考虑数据库、表和字段结构。因此，不建议采用静态接口技术，如将 SQL 语句嵌入典型的 3GL 中（即嵌入式 SQL API - ISO SQL - 92 标准），而应使用通用接口。 当代 RDBMS 在嵌入式 SQL 框架中提供了动态 SQL 功能，允许在不事先了解数据库模式、表和字段结构的情况下执行任何类型的语句。动态 SQL 语句可在运行时构建并放入字符串主机变量中，然后提交给 RDBMS 处理。不过，由于 RDBMS 需要在运行时为动态 SQL 语句生成访问计划，所以动态 SQL 比静态 SQL 慢。在这种架构中，真正的好处在于将动态 SQL 部分（数据库守护进程）与实际的网关实例分离。 另一种通用访问 DBMS 的选项是 SQL 调用级接口（CLI）。SQL CLI 最初由 SQL 访问组（SAG）定义，为远程数据访问提供统一标准。CLI 需要智能数据库驱动程序，将调用转换为本地数据库服务器的访问语言。CLI 被前端工具用于访问 RDBMS，后者需包含相应的驱动程序。每个连接的数据库都需要一个驱动程序，且每个驱动程序都要针对特定服务器编写。SAG API 基于动态 SQL，语句需要先准备再执行。1994 年秋季，SAG CLI 成为 X/Open 规范，后来成为 ISO 国际标准（ISO 9075 - 3）。实际上，X/Open CLI 是一个 SQL 包装器，是基于 SQL 的 DBMS 函数库，可由应用程序调用。 微软的开放数据库连接性（ODBC）API 基于 X/Open CLI。1992 年推出的 ODBC 1.0 版本因性能不佳和文档有限而受到广泛批评。最初，ODBC 仅限于 MS Windows 平台，后来移植到其他平台，如 Sun 的 Solaris。1994 年发布的 ODBC 2.0 有了显著改进，32 位支持提高了新 ODBC 驱动程序的效率。1996 年，微软推出 ODBC 3.0。如今，大多数数据库供应商（如 Oracle、Informix、Sybase）除了支持其本地 SQL API 外，还支持 ODBC API。然而，ODBC 技术存在一些问题，如架构的额外层会带来大量开销（特别是在 SQL 更新和插入操作中），且该规范完全由微软控制。OLE/DB 框架的引入也让人怀疑微软是否会进一步推进 ODBC 的发展。 随着 Java 编程语言的出现，新的 SQL CLI——JDBC（Java 数据库连接性）应运而生。JDBC 是由 Javasoft、Sybase、Informix、IBM 等供应商联合开发的，是一种便携式、面向对象的 CLI，完全用 Java 编写，与 ODBC 非常相似。它允许开发独立于 DBMS 和执行平台的 Java 代码。JDBC 的架构与 ODBC 类似，引入了驱动程序管理器（JDBC 驱动程序管理器）来控制各个 DBMS 驱动程序。应用程序与驱动程序管理器共享一个公共接口。JDBC 驱动程序可分为直接驱动程序和 ODBC 桥接驱动程序，具体有四种类型： | 驱动类型 | 特点 | 适用场景 | 性能 | | ---- | --