本文詳細介紹了SQL Server對XML支持，其中增強的特性，全新的面向XML的存儲體系，SQL Server認證機制的安全性改進，分級的數據庫訪問實體機制，借助CLR控制.Net Assembly的執行過程，上下文定義特性等。
Internet：我用最XML的方式支持你
SQL Server對XML支持
Internet平台應用除了通信部分與其他應用有本質區別外，作為基本的應用組成沒有實質區別，無非是處理邏輯和業務數據模型。在HTTP為基礎的Internet上，XML數據通過自描述性、可擴展能力和跨平台優勢，獲得了包括微軟在內的數據廠商的支持，因此作為微軟整個.Net計劃的中心產品——SQL Server 2005也要順應應用趨勢，面向XML尤其是XML Web Service提供存儲、發布、交換和整合的支持。
SQL Server 2000的時候已經增加了對XML的支持，而且可以通過HTTP訪問獲得XML數據，相應的開發也通過SQLXML單獨安裝開發包，不過在SQL Server 2005中對XML數據訪問的支持有了大幅度增強。
對XML支持的增強特性
（1）增加了專門的XML數據類型。
（2）提供了對XQuery的全面支持，可以通過XQuery在關系數據庫的基礎上，通過查詢引擎把二維的關系數據結果組織成層次型的XML數據。
（3）不僅提供查詢，SQL Server 2005還一並提供了XML DML，可以通過INSERT、UPDATE、DELETE完成對XML數據片段的修改。
（4）與以往關系數據庫索引不同，新的數據庫引擎還提供面向XML數據的層次性索引，統一XML索引解決了以往開發人員對於在已知Schema上批量數據快速查詢的支持。
（5）通過增強分布式查詢的OPENROWSET的功能，提高同構甚至異構系統間批量XML數據的處理效率。
（6） 此外，對於SQL Server 2000引入的FOR XML子句和OPENXML()提供更好的支持。
全新的面向XML的存儲體系
在新的平台上，普遍的開發技術組合是 ADO.Net 2.0 + XML + SQL Server。即便在國內這種開發模式已經非常普遍，已經用於在建的很多項目，況且在微軟的家族內部報表服務、集成服務、數據分析服務已經全面支持XML，而且在開發領域.Net的配置文件也是XML，甚至ADO.Net用戶交換的DataSet和DataTable都是完全可以XML化的。但是，以往的SQL Server產品沒有辦法解決存儲上的沖突，層次結構的XML雖然被保存到了關系數據庫裡面。由於一般采用BLOB方式，因此只能以高前端程序討論XSD或者DTD進行驗證。而且由於以前沒有配備XML索引，因此進行檢索需要逐個把BLOB中的數據提取出來之後，再進行比較，這樣效率非常低。為了提高效率以往還采用拆分XML文件，通過XML VIEw借助關系數據庫的查詢優化來減少這種批量檢索的性能損失。總而言之，SQL Server 2000處理XML到處都感覺比較“別扭”。
有了SQL Server 2005的混合存儲之後，筆者認為新的體系對XML使用有如下好處：
（1）對於商業應用要求而言，關系數據與XML數據都有了事務性的保證。
（2）面對專門的XML數據對象，可以通過配置XSD或者DTD驗證數據。
（3） 對於應用開發而言，提供了與ADO.Net同樣的模式。
（4）可以在混合結構上通過索引進行快速檢索。
（5）對於管理員而言，可以進行統一的備份/恢復、授權、訪問控制、復制、數據集成調度。
是你嗎？不管怎麼說我的數據我做主
作為您或者您的企業的關鍵數據的中心載體，進行必要的安全保護將是保證業務系統正常運轉的必要條件，當然實現這個目標需要開發和運行維護團隊人員根據數據庫的功能特性進行集成和配置。
SQL Server認證機制的安全性改進
圖1：SQL Server的認證機制
如上圖，SQL Server認證同時提供SQL Server本地賬號與Windows繼承認證兩種方式，以往在企業環境中相信讀者可以通過配置活動目錄的密碼策略來控制諸如下面一些策略：
（1）是否采用強密碼
（2）密碼長度
（3）密碼過期時間
（4）驗證錯誤鎖定次數
（5） 賬號是否Enable
而在SQL Server 以往的版本中本地賬號上這些控制似乎很弱。在SQL Server 2005中，所有的Login不僅可以通過“用戶名/密碼”方式進行認證，還可以通過證書方式進行，這對於具有異構操作系統平台的企業CA環境而言，提供了最為便捷的方式。對於Login Policy的配置可以通過內值函數LOGINPROPERTY獲得，了解相關的配置策略信息。
圖2：配置Login的密碼策略
代碼示例1：通過LOGINPROPERTY獲得Login的安全策略
LOGINPROPERTY ( 'login_name' ,
{ 'IsLocked' | 'IsExpired' | 'IsMustChange'
|'BadPasswordCount' | 'BadPassWordTime'
| 'HistoryLength' | 'LockoutTime'
| 'PasswordLastSetTime' | 'PassWordHash' } )
示例1．確認用戶是否需要修改密碼
SELECT LOGINPROPERTY('WillisJO', 'IsMustChange');
GO
示例2：確認Login是否已經被鎖定
SELECT LOGINPROPERTY('SamirK', 'IsLocked');
GO
分級的數據庫訪問實體機制
在以往的SQL Server中，SQL Server采用的是SQL Server Instance層次的Login和數據庫層次的Role、User，總而言是從SQL Server自身的角度確認那些訪問實體（用戶或者是應用程序）可以訪問數據庫。SQL Server2005 按照訪問的范圍把訪問實體化分為三大類Principal：Windows級、SQL Server級和Database級。具體包括如下。
Windows-級的Principal：Windows Domain login、Windows Local login
SQL Server級的Principal：SQL Server login
Database級的Principal：Database User、Database Role、Application Role
SQL Server 2005中增加了一個新的概念——Securable，它代表由數據庫引擎控制訪問的各種數據庫資源。根據三層訪問實體的劃分，對應的在每個層次也出現了不同的Securable對象，如下說明。
數據庫服務器范圍內的：EndPoint、Login、Database
數據庫范圍內的：User、Role、Application role、Assembly 、Message Type、Route、Service 、Remote Service Binding、Fulltext Catalog、Certificate、Asymmetric Key 、Symmetric Key 、Contract、Schema
而在Schema范圍內：Type 、XML Schema Collection 、Object
Object他包括如下幾類：Aggregate、Constraint、Function 、Procedure、Queue、Statistic、Synonym 、Table、VIEw
因此，在明確了Principal、Securable和Object三者關系之後，每一個Principal對於SQL Server的訪問控制就可以通過如下關系獲得：
圖3：配置Principal、Securable與Securable的關系
在明確上文分層的Principal和分層的Securable之後，相信讀者自然而然會發現其實在SQL Server 2005的設計中，權限（Permission）本身也是具有層次性的，可以用DCL語言（GRANT、DENY、REVOKE）來管理與配置它們。下圖是一個完整的SQL Server 2005Principal、Securable和Permission的層次嵌套關系：
圖4：Principal、Securable和Permission層次嵌套關系
在Management Studio中的配置界面如下：
圖5：配置Principal對Securable訪問權限的過程
借助CLR控制.Net Assembly的執行過程
如上文所說，SQL Server 2005繼承了CLR，同時也就將CLR對於.Net Assembly的控制集成到了他的安全體系之中，目的是要確保功能強大的.Net代碼不至於傷害到SQL Server或者是他的運行環境。默認情況下SQL Server 2005提供了Safe（安全訪問SQL Server內部數據）、External_Access（以托管方式可以訪問SQL Server內部或部分外部資源）和Unsafe（非托管方式，可以直接訪問系統平台接口和本地Windows 32 API）三個代碼執行范圍等級。通過對.Net Assembly配置執行范圍等級，可以粗略的控制代碼訪問范圍。不過筆者更建議讀者通過配置.Net Framework Configuration完成，這樣做的主要好處是一方面可以很容易的通過域策略將配置好的模版作分發，對於整個企業運行環境進行集中管理有很大好處。
“看我七十二變的”的上下文定義特性
相信以往信息上線的時候，數據庫應用開發人員與數據庫管理人員可能會因為應用需要過多的執行能力發生爭執，作為數據庫管理員（DBA）一般都是按照最小化原則配置訪問權限，並且希望應用的執行賬號（企業應用中常常會采用代理賬號訪問數據庫）盡量限制在其自己的Schema內部，尤其不要訪問注冊表、活動目錄、媒體資料庫等敏感的系統資源。但是，應用規模大了難免出現個別特例，萬般無奈之下數據庫管理員只得為應用的賬號配置一個BUILDIN / Administrators或者Domain Admins級別的權限。這樣，如果一旦出現代碼注入等問題的時候，威脅的不僅僅是數據庫本身，甚至是下層的Windows運行環境。
SQL Server 2005的Executing Context提供了“七十二變”的辦法，可以為調用鏈中的某個執行步驟配置不同的用戶身份，這樣即便出現個別系統敏感訪問的時候，也只需要為這些步驟配置單獨的執行賬號。
圖6：執行過程中交換Context的示例
