通过集成CLR,SQL Server 2005已经获得了很多新的特性,借助CLR的集成可以用任何.NET语言建立存储过程、触发器、用户自定义函数、用户自定义类型、用户自定义聚合。通过这个集成笔者认为SQL Server主要可以获得如下优势。
提供了一个更加完善的开发模型,对于熟悉面向对象的开发人员和一直在SQL Server平台进行T-SQL开发的开发人员都提供开发的舞台。更深层次讲,这两类开发人员可以根据自己熟悉的领域对应用进行优化,T-SQL开发人员可以根据执行计划分析和优化应用,面向对象开发人员可以根据已有的Best Practice,借助代码复查以优化自己的应用。
提供了更好的安全性,这个主要来源于CLR运行于托管环境的原因,通过运行过程中CAS(Code-Access Security),所有的代码执行过程都是在一个安全的调用链运行,与以往不同的是,即便用户获得了某个已开发好的功能的使用权限,但是如果该功能所使用的某个组件的安全性与目标资源的安全性相冲突,也会被CLR判断为非法。
以往的代码面临的主要安全问题如下:
1.非授权使用或者越权使用;
2.代码注入;
3.额外信息泄漏;
4.伪装、欺骗代码执行;
498)this.style.width=498;">
图1:执行过程中代码主要面临的安全问题
那么在CLR中,执行每一个Assembly的时候都要基于既有的或者定制的安全策略进行访问检查,不仅仅是调用者权限检查,也包括用户与目标资源之间的访问关系,更为主要的是在每个功能调用的过程中,还要检查每上游组件的安全要求是否与自身安全要求抵触,如果出现异常,那么这个调用链也会被终止。执行过程如下:
498)this.style.width=498;">
图2:单个Assembly的执行过程
498)this.style.width=498;">
图3:Assembly调用链的安全检查
这样做的好处在于:可以大大丰富SQL Server的对象系统。
相信很多T-SQL设计人员在进行数据库设计的时候,会碰到因为相对非常有限的数据类型无法描述业务对象的情况。但有了CLR的支持,SQL Server 2005可以描述的对象系统基本上扩展为无限。但是,笔者这里根据经验提醒用户在使用该功能的时候要注意如下几个内容:
1.设计新的数据对象要考虑到中间结果的存储问题。
2.涉及到查询的时候还是要考虑采用T-SQL,这主要是出于效率问题。
3.尽可能考虑到事件、Delegate回调对于处理性能的影响,不是必要的话尽量不用。
可以把整个开发的流程完全集成到统一的Visual Studio 2005中,全开发生命期可以在一个框架下完成。
更深层次讲,在完成统一个项目的时候,可以充分利用CLR进行复杂数据结构的计算能力效率和T-SQL的关系数据处理能力优势。
开发基于CLR的数据库对象
通过CLR的集成,可以在SQL Server 2005中建立如下的一些数据类型:
Scalar-valued user-defined functions (scalar UDFs)
Table-valued user-defined functions (TVFs)
User-defined procedures (UDPs)
User-defined triggers
上述四个类型算是基本的数据类型,因为它可以直接地映射到类的公共静态方法,除此之外还可以定义更为复杂的用户聚合函数。由于受到访问能力的限制,在SQL Server 2000中用户自定义函数能访问的对象有限,但是SQL Server 2005借助.NET平台甚至于可以把一些计算通过协调远端的Web Service一并完成。
笔者认为,在SQL Server 2005平台上,开发人员的思维要具有扩展性,不仅要考虑SQL Server 本身支持的内容,还要考虑到Windows平台支持的内容、企业内部SOA其他应用的支持,直至整个Internet环境下的任何可以用资源。
498)this.style.width=498;">
图3:CLR支持后扩展数据对象的资源分布
相对而言,开发User-Function和User-Defined Procedure都是比较容易,这里笔者就开发CLR 触发器作些说明。正如大家所知,Trigger主要包括两类:“DML 触发器”和“DDL 触发器”。DML触发器主要在DELETE、UPDATE、INSERT的时候触发,DDL 触发器则会在CREATE、ALTER、DROP的时候触发。在使用T-SQL编写触发器的时候可以通过INSERTED和DELETED这两个虚表,结合COLUMN_UPDATED()函数完成DML事件的响应。在集成了CLR之后,用.NET语言写触发器可以访问如下内容:
继续访问DELETED和INSERTED这两个虚表;
通过UPDATE操作,判断哪些列受到了修改;
通过访问数据库对象获得DDL的执行语句;
除此而外,开发CLR 触发器的时候还可以通过SqlContext.TriggerContext获得当前操作的上下文,明确究竟是DML的INSERT、UPDATE、DELETE,还是DDL的CREATE、DROP、ALTER操作。
代码示例1:INSERT或DELETE操作的DML触发器写法
|
代码实例2:判断哪些列被UPDATE
|
代码实例3:通过访问Context判断DLL操作的内容
|
SQL Server 2005上的ADO.NET 2.0
SQL Server 2005对于应用开发业提供了一系列新的功能,不过很多需要通过ADO.NET 2.0来访问。根据笔者的经验,如果您确定您的产品或者项目依托于SQL Server 2005,而不是做数据库产品无关的通用产品的话,完全可以考虑这些新的特性,但是要注意这些特性很可能会改变您的很多应用架构。
不会影响到系统构架的新特性如下:
(1)新的数据类型,包括XML数据;
(2)支持Snapshot级的事务隔离级别;
(3) 支持系统快速高可用功能的Mirroring;
但是,下面一些功能将会影响到您的系统架构:
(1)一步的SQL Server访问
(2)MARS (Multiple Active Result Set),不仅可以让您复用与数据库的连接,而且还可以在源数据更新的时候,主动根据SQL Server触发更新。
事务的控制上,ADO.NET 2.0可以借助SQL Server自己的事务机制或者System.Transactions的支持,可以用非常简单的方式使用本地或者分布式事务。如果你的数据操作仅仅限于当前一个固定的SQL Server,那么笔者建议您采用Promotion的轻量级交易机制。你所要做的就是在SqlConnection的ConnectionString属性定义时增加一个Enlist关键字即可,这样当你的ADO.NET访问涉及DML操作时,CLR会自动为您增加一个事务,保证操作的原子性。但如果你的操作不仅仅限于当前SQL Server,还要访问其他异构数据库或者队列之类的其他对象,那么您需要分布式事务的支持,这时候您需要在DTC的调度下,同时使用SQL Server 2005本地事务、System.Transactions和System.Data.SqlClient三者,把整个处理包装到一个代价比较昂贵的分布式交易中。总而言之,到底要使用那种事务处理,要看您的应用需要。
笔者要提醒您注意的是,在CLR的托管代码支持下,SQL Server 2005采用CLR 事务和T-SQL的事务有很大的区别:
CLR中定义的包括事务的处理内容必须被ROLLBACK或者COMMIT,除非SQL Server在处理内容没有执行结束之前出现严重错误,导致内容不能执行结束。
(1)出现事务嵌套时,内部事务不可以ROLLBACK或者COMMIT外部的事务。
(2)不要试图提交非本Function或者Procedure的事务,这样会导致Run-Time Error。
(3) 试图回退非本Function或者Procedure的事务时,会导致事务执行挂起,借助该特性可以用来调试事务内部的内容。
XML的串行化支持
SQL Server 2000仅仅提供了有限的HTTP直接访问支持,但是在引入了CLR 集成后,Internet / Intranet应用可以借助于XML串行化,直接以XML方式访问系统的用户自定义类型数据,尤其对于给予HTTP访问BLOB对象的时候也可以支持,此外可以在SQL Server内部通过该特性访问Web Service。