除了我们在前面已经提到的局限性，即 DB-Library 仍然只能使用 SQL Server 6.5 版，TDS 协议对于所有 API 都是相同的。ODBC 和 OLE-DB 在与 SQL Server 7.0 通信时使用 SQL Server 7.0 版，但也能够与 6.5 或 6.0 服务器通信。另一个是 Net-Library，这是一个抽象层，客户机和服务器都在此层上同网络抽象接口通信，不必为 IPX 还是 TCP/IP 困扰。在这里我们将不讨论 Net-Library 的工作细节；只要知道它们的工作基本上是将来自的网络通信底层的细节隐藏起来不让软件的其他部分看到就可以了。
从客户机的角度看服务器
前面已经提到过，客户机与 SQL Server 通信的主要方法就是通过使用 TDS 消息。TDS 是一种简单协议。当 SQL Server 接收到一条消息时，可以认为是发生了一个事件。首先，客户机在一个连接上发送登录消息（或事件），并得到返回的成功或失败的响应。当您希望发送 SQL 语句时，客户机可以把 SQL 语言消息打包发送给 SQL Server。另外，当您希望调用存储过程、系统过程或虚拟系统存储过程（我们后面还要详细讨论）时，客户机可以发送 RPC 消息，这种消息相当于 SQL Server 上的一个 RPC 事件。对于上面的后两种情况，服务器会以数据令牌流的形式送回结果。Microsoft 没有把实际的 TDS 消息写入文档中，因为这被认为是 SQL Server 组件之间的私用契约。
目录存储过程是另一类关键的客户机/服务器的交互部分。这些存储过程首先在 ODBC 的 SQL Server 6.0 中出现, 包括诸如 sp_tables 和 sp_columns 等存储过程。ODBC 和 OLE-DB API 定义了描述有关数据库对象的元数据的标准方法，这些标准需要适用于所有类型的 RDBMS 服务器，而不必调整为 SQL Server 自己的系统表。不是客户机向服务器发送对系统表的多个查询，并在客户机端建立标准的元数据视图，而是创建一组存储在服务器上的系统存储过程，并对 API 返回适当格式的信息。这种方法使得通过一次通信就可以完成很多重要的元数据请求。
为 ODBC 编写的过程已经写入文档，通常适合需要从系统表中获取信息但其他机制没有提供这种方法的情况。这使得 Transact-SQL 过程和 DB-Library 应用程序可以访问元数据，而不需要编写对 SQL Server 系统表的复杂查询，并且使应用程序不受今后 Microsoft 修改系统表的影响。
OLE DB 定义了一组架构行集，它们类似于 ODBC 的元数据，但又和它不同。它创建了一组新的目录存储过程，以更有效地为这些架构行集植入数据。但是，这组新的存储过程没有写入文档，因为这些存储过程重复了早先提供的功能。通过现有的若干种方法都可以得到元数据，因此 SQL Server 开发组决定不显露这些并没有为编程模型增加新内容的对象。
客户机与服务器的交互还有第三个方面。它最初出现在 SQL Server 6.0 中，但是没有得到普遍使用。这就是虚拟系统存储过程的概念；在 SQL Server 7.0 中起很重要的作用。当第一次为 SQL Server 6.0 开发服务器端游标时，开发人员就需要选择采取什么方法管理客户机/服务器的交互。游标并不特别适合现有的 TDS 消息，因为这些消息允许逐行返回数据，不需要客户机指定额外的 SQL 语句。开发人员本来可以向 TDS 协议添加更多的消息，但是需要修改太多的其他组件。SQL Server 6.0 中的 TDS 版本还需要向 Sybase 版本靠拢，以便确保两者的可互操作性，于是开发人员选择了另外的处理机制。他们开发了外表看起来像是系统存储过程的新功能（服务器端游标），实际上是指向 SQL Server 代码的入口存储过程。它们被客户机应用程序使用标准的 RPC TDS 消息来调用。它们被称为虚拟系统存储过程，因为在客户机上，它们像其他存储过程那样被调用，和其他存储过程不同的是，它们并不是由简单的 SQL 语句组成。大多数虚拟系统存储过程都是私用的，并且没有写入文档。对于游标过程，所有 API 都显露其自有的一组游标 API 模型和它们自己的游标操作函数，因此没有必要为存储过程本身编写文档。即使是在 Transact-SQL 语言中，也有显露游标的语法，可以使用 DECLARE、OPEN、FETCH 等，所以完全没有必要为虚拟系统存储过程编写文档，例如 sp_cursor，因为这些过程只在内部使用。
ODBC 和 OLE DB 中出现了带参数的查询和准备/执行模型的概念。在 SQL Server 7.0 以前的版本中，这些概念是由客户机 API 中的代码实现的。在 SQL Server 7.0 中，Microsoft 为这些概念添加了对“关系服务器”的支持，并且通过新的虚拟系统存储过程显露了这种支持。本文后面还要介绍这些功能，以及服务器如何支持这些功能。通过 sp_executesql 过程对带参数的查询的支持，被认为对直接 Transact-SQL 和 DB-Library 的使用特别有用，所以将其写入了文档。准备/执行的过程，被 ODBC 驱动程序和 OLE DB 提供程序专用。
这样，可以与 SQL Server 通信的所有客户机程序，都建立在这三组功能之上：TDS 协议、目录存储过程和虚拟系统存储过程。
服务器结构
SQL Server，或更确切一点地说，是“SQL Server 关系服务器”，经常被说成是由两个主要部分组成，即关系引擎和存储引擎。正如前面提到过的那样，已经有很多文献介绍存储引擎的细节了，所以本文主要介绍关系引擎的功能。图 3 给出了 SQL Server 关系引擎部分的主要组件。所给出的组件可以分为三组子系统。左边的组件编译查询，包括查询优化器。查询优化器是所有关系数据库引擎中的最神秘的部分之一，从性能的角度看也是最重要的部分。查询优化器负责提取 SQL 语句中的非过程请求部分，并将其翻译成一组磁盘 I/O、过滤以及其他能够高效地满足该请求的过程逻辑。图中右侧是执行基础结构。这里实际上只有很少的功能。当编译组件的工作完成之后，所产生的结果只需用很少几个服务即可直接执行。
图 3. 服务器结构
图的中间是称为 SQL Manager 的部分。SQL Manager 控制着 SQL Server 内部的所有数据的流动。SQL Manager 控制着 RPC 消息，在 SQL Server 7.0 中，绝大多数来自客户机的功能调用都是通过 RPC 消息进行的。上一节中介绍的虚拟系统存储过程逻辑上也是 SQL Manager 的一部分。通常，作为 TDS SQL 语言消息的 SQL 语句直接在编译一端执行，与早期版本相比，SQL Server 7.0 较少使用这种方法，但还算是比较常见的。执行结果由称为 ODS 的执行引擎中的组件格式化为 TDS 执行结果消息。
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
