摘要
本文介紹了在客戶機上處理 Microsoft SQL Server 查詢的方式
各種客戶機與 SQL Server 的交互方式
以及 SQL Server 在處理客戶機程序的請求時需要完成的工作
簡介
Microsoft(R) SQL Server(TM) 內部機制和結構是一個非常大的主題
因此本文僅限於程序開發人員感興趣的問題
集中研究其他源中沒有徹底討論的問題
在討論 SQL Server 的結構時
我們主要觀察客戶機的處理過程
研究不同的客戶機程序與 SQL Server 的交互方式
以及 SQL Server 如何處理客戶機的請求
還有一些討論 SQL Server 其他方面的信息源
特別是 Microsoft Press 出版的 Inside SQL Server
作者是 Ron Soukup 和 Kalen Delaney
這本書非常詳細地討論了 SQL Server 存儲引擎的內部機制和處理方法
不過對查詢處理器的討論不夠深入
本文正填補了這個空白
我們期望本文有助於讀者編寫出更好的應用程序
通過本文
讀者會在提高程序性能方面得到新的啟發
產生新的理解
SQL Server 是一種客戶機/服務器系統
多年來
SQL Server 一直被認為是一種客戶機/服務器系統
事實上
Sybase DataServer（以此為基礎開發了原始的 SQL Server）正是第一個作為客戶機/服務器系統開發的商用關系數據庫系統
那這又說明了什麼呢？這不只意味著 SQL Server 是一個雙層系統
從傳統上看
雙層系統意味著客戶機應用程序運行在一台機器上
向另一台計算機上的服務器發送請求
而對於 SQL Server
客戶機/服務器意味著 SQL Server 的組成部分
即客戶機 API 部分
駐留在處理結構中的遠端
與服務器組件本身是分開的
在典型的雙層模型中
客戶機程序部分駐留在台式機上
具有大量客戶機應用程序邏輯和業務邏輯
並且會直接向數據庫系統發出請求
然後
客戶機得到服務器響應這些請求所返回的數據
三層系統也采用了同樣的模型
多年以來
SQL Server 一直用在事務處理監視系統中
例如 BEA 的 Tuxedo 以及 Compaq 的 ACMSxp
這些系統早在二
三十年前就采用了典型的三層模型
三層模型在今天基於 Web 的應用系統中占據了支配地位
這類系統以 Microsoft 的 MTS 以及新的 COM+
為代表
從 SQL Server 的角度看
三層解決方案中的客戶機程序是放在中間層的
中間層直接與數據庫交互
實際的桌面
或瘦客戶機(Thin Client)
使用其他機制並通常直接與中間層交互
而不是直接與數據庫系統交互
圖
描述了這種結構
圖
三層系統模型
客戶機結構
從結構的角度看
SQL Server 關系服務器組件本身並不真正關心客戶機程序運行的位置
事實上
就 SQL Server 而言
即使在運行 SQL Server 的同一台機器上運行應用程序
仍然還是客戶機/服務器模型
服務器運行一個單獨的多線程進程
為來自客戶機的請求提供服務
不管客戶機的位置在哪裡
客戶機程序代碼本身是單獨的運行在客戶機應用程序內部的 DLL
與 SQL Server 的實際接口是在客戶機和服務器之間對話的
表格數據流
(Tabular Data Stream
TDS) 協議
一個常見的問題是
什麼是 SQL Server 的本機接口呢？
很長時間以來
很多開發人員一直都不願意使用 ODBC 這樣的接口
因為他們認為由 Sybase 開發的客戶機 API
也就是 DB
Library
是 SQL Server 的本機接口
實際上
SQL Server 關系服務器本身並沒有本機 API
它的接口就是在客戶機和服務器之間的通信流協議 TDS
TDS 把客戶機發送給服務器的 SQL 語句封裝起來
也把服務器返回給客戶機的處理結果封裝起來
任何直接處理 TDS 的 API 都是 SQL Server 的本機接口
讓我們來看一下客戶機的組件
如圖
所示
客戶機結構中的某些部分就不在這裡討論了
因為它們不屬於 SQL Server 的范疇
但如果您在編寫應用程序的話
就必須了解這些部分
大家知道得最多的應該是各種對象模型
如果您正在編寫 ASP 或 Microsoft Visual Basic(R) 應用程序
就需要通過 ADO 與數據庫系統交互
而不是直接調用底層的 API
例如 ODBC 或 OLE
DB
ADO 映射到 OLE
DB
而 RDO 映射到 ODBC
因此
作為這種最常用的編程模型的對象模型
並不是 SQL Server 客戶機結構中的嚴格意義上的組件
此外
還有另外一些組件可以插接到 SQL Server 基礎結構上面的這一層
OLE
DB 的
會話池服務提供程序 (Session Pooling Service Provider)
就是這種組件的一個例子
圖
客戶機結構
客戶機接口
SQL Server 有兩個接口可以認為是 SQL Server
的本機接口
即 OLE
DB 和 ODBC
DB
Library 接口也是本機的
它與 TDS 通信
但是 DB
Library 使用的是 TDS 較老的版本
需要在服務器上進行一些轉換
現有的 DB
Library 應用程序仍然可以繼續與 SQL Server
協同使用
但是很多新的功能和性能提高等好處只能通過 ODBC 和 OLE DB 才能利用
更新 DB
Library 使其支持 SQL Server
的新能力
將會導致與現有應用程序的很多不兼容性
因此需要修改應用程序
ODBC 在五年之前就替代了 DB
Library
是新的 SQL Server 應用程序更理想的 API
因此引入不兼容的 DB
Library 新版本並不明智
從圖
可以看到
所有這些客戶機 API 都有三個部分
最上面的部分實現 API 的細節
例如行集和游標應該是什麼樣等等
TDS 格式化程序負責處理實際請求
例如 SQL 語句
並將其封裝成 TDS 消息包
發送給 SQL Server
獲得返回的結果
然後再把結果反饋到接口實現
還有一些供所有提供程序使用的公共庫代碼
例如
BCP 設備就是 ODBC 和 OLE
DB 都可以調用的庫
DTC 也是這樣
第三個例子是 ODBC 規范的 SQL 語法
即帶有參數標記的 CALL 語法
這些對於所有提供程序都是通用的
除了我們在前面已經提到的局限性
即 DB
Library 仍然只能使用 SQL Server
版
TDS 協議對於所有 API 都是相同的
ODBC 和 OLE
DB 在與 SQL Server
通信時使用 SQL Server
版
但也能夠與
或
服務器通信
另一個是 Net
Library
這是一個抽象層
客戶機和服務器都在此層上同網絡抽象接口通信
不必為 IPX 還是 TCP/IP 困擾
在這裡我們將不討論 Net
Library 的工作細節
只要知道它們的工作基本上是將來自的網絡通信底層的細節隱藏起來不讓軟件的其他部分看到就可以了
From:http://tw.wingwit.com/Article/program/SQLServer/201311/22011.html
