SQL Server 2005中的CLR(2)
导读部分
------------------------------------------------------------------------------------------------------------- SQL Server 2005 学习笔记系列文章 http://www.sufeinet.com/thread-26-1-1.html
这一节咱们来说说ClR的性能，我们不能只使用它而不去考虑到低 为什么要使用它或是在什么时候应该使用它，像我之前写的函数得到一个字符的长度的方法就没有太大必要了，但如果是像拆分字符这样的方法应该就有必要了，比如c#里的Split ()方法，在Sql里就没有这样的函数这个时候 我们就可以使用Clr来完成了，其实实现 的方法是跟上一节SQL Server 2005中的CLR(1)里的没有任何分别只是把函数的代码换成下面的代码就可以了
[code=csharp]using System;
using System.Data;
using System.Data.SqlClient;
using System.Data.SqlTypes;
using Microsoft.SqlServer.Server;
CLR 与 XP
在 SQL Server 以前的版本中，扩展存储过程 (XP) 为数据库程序开发人员提供了唯一可用的机制来编写服务器端逻辑，这要么难于表示，要么不可能用 T-SQL 编写。CLR 集成提供了一种更健壮的替代方法来编写这种存储过程。此外，使用 CLR 集成，过去以存储过程形式编写的逻辑通常可以更好地表示为表值函数，因为它们允许它们允许将该函数构造的结果放在 SELECT 语句中进行查询（通过将这些结果嵌入到 FROM 子句中）。
以下是使用 CLR 过程或函数与 XP 相比的优势：
• 粒度控制：很少可以控制 XP 能做什么或者不能做什么。使用代码访问安全模型，SQL Server 管理员可以分配三种权限之一：SAFE、EXTERNAL_ACCESS 或 UNSAFE，从而对托管代码允许进行的操作集进行不同程序的控制。
• 可靠性：托管代码（特别是在 SAFE 和 EXTERNAL_ACCESS 权限集中）提供了比 XP 更安全、更可靠的编程模型。可验证的托管代码确保了所有对对象的访问都是通过强类型化的接口实现的，从而降低了程序访问或破坏属于 SQL Server 的内存缓冲的可能性。
• 数据访问：使用 XP£¬编程人员必须向后显式连接到数据库（称为回环），以访问本地 SQL Server 数据库。而且，必须将此回环连接显式绑定到原来的会话事务上下文，以确保 XP 可以参与到调用它的同一个事务中。通过托管代码，可以使用更自然和更有效的编程模型来访问本地数据，这些模型利用当前的连接和事务上下文。
• 性能：System.Data.SqlServer API 允许托管过程将结果集发送回客户端，其性能比 XP 使用的开放式数据服务 (ODS) API 更好。此外，System.Data.SqlServer API 支持新的数据类型（如 SQL Server 2005 中引入的 XML、(n)varchar(max)、varbinary(max)），而没有扩展 ODS API 来支持这些新的数据类型。
• 可伸缩性：通过托管代码，SQL Server 可以管理资源（如内存、线程和同步）的使用，因为公开这些资源的托管 API 是在 SQL Server 资源管理器上实现的。相反，SQL Server 不能查看或控制 XP 的资源使用情况。举例来说，如果 XP 消耗了太多的 CPU 或内存资源，就没有办法使用 SQL Server 来检测或控制。然而，通过托管代码，SQL Server 可以检测到特定线程在一段很长的时间内一直没有退出，然后就强制该任务退出，这样其他工作可以按计划进行。因此，使用托管代码提供了更好的可伸缩性和健壮性。
正如上面所提到的，在数据访问和发送结果集给客户端方面，CLR 过程比 XP 做得更好。对于不包括数据访问和发送结果的代码，比较 XP 和托管代码的性能就是比较托管代码和原生代码的性能。一般来说，在这些情况下托管代码比不上原生代码的性能。而且，当在 SQL Server 内运行时，从托管代码到原生代码的事务处理过程有额外的开销，因为在移动到原生代码和从原生代码移回时，SQL Server 需要对特定于线程的设置进行额外的登记-保留。因此，对于在托管代码和原生代码之间有频繁的事务处理的情况，XP 大大地胜过在 SQL Server 内部运行的托管代码。
对于大多数扩展过程，如果考虑数据访问和结果发送的可伸缩性、可靠性和性能优势，CLR 过程提供了更好的替代方法。对于性能主要是由处理（数据访问和结果发送之外的）和频繁的托管-原生转换决定的情况，应该权衡 CLR 的可伸缩性和可靠性的优势与 XP 的原始性能优势。
下面我以一个实例的方式来说明它的用法，我们来处理一下一个字符串是否是数字字符;
我们还是打开上次的项目，右击项目---添加--新建项
我们添加一个Xp，名称为RegexNumber
生成的代码如下
[code=csharp]using System;
using System.Data;
using System.Data.SqlClient;
using System.Data.SqlTypes;
using Microsoft.SqlServer.Server;
public partial class StoredProcedures
{
[Microsoft.SqlServer.Server.SqlProcedure]
public static void RegexNumber()
{
// 在此处放置代码
}
};[/code]
我们做一下修改就可以变成我们想要的代码了，修改完成的代码如下
[code=csharp]using System;
using System.Data;
using System.Data.SqlClient;
using System.Data.SqlTypes;
using Microsoft.SqlServer.Server;
using System.Text.RegularExpressions;
public partial class StoredProcedures
{
[Microsoft.SqlServer.Server.SqlProcedure]
public static int RegexNumber(string inputData)
{
// 存储过程只能返回int类型在这里
if (IsNumber(inputData))
{
return 1;
}
else
{
return 0;
}
}
/// <summary>
/// 是否数字字符串
/// </summary>
/// <param name="inputData">输入字符串</param>
/// <returns></returns>
public static bool IsNumber(string inputData)
{
Regex RegNumber = new Regex("^[0-9]+$");
Match m = RegNumber.Match(inputData);
return m.Success;
}
};[/code]
我们现在右击项目选择部署项目，然后打开数据库查看一下吧
当然执行这个存储过程跟我们平时执行过程 的方法是一样的，下面看看执行结果吧
大家还可定义一下其它 的身份证码号，邮件等，在这里只是做一下存储的使得方法;对于程序本身是否有介值不做审议;
接下来简单介绍一下关于Clr其它方面的东西
代码位置：数据库与中间层
通过在数据库中提供丰富的编程模型，CLR 集成提供了将逻辑从其他层移动到数据库层的选择。然而，这显然并不意味着所有或大部分逻辑应该移到数据库中。
将逻辑移到数据库层可以减少网络中的数据流量，但是增加了服务器上宝贵的 CPU 资源的负荷。因此，在应用程序中做出代码放置的决定之前，要慎重权衡。以下注意事项适用于将数据库层作为首选的代码位置：
• 数据验证：在数据层进行数据验证的逻辑可以更好地将数据和逻辑封装在一起。这样避免了在不同数据接触点（如：后端处理、批量上载和来自中间层的数据更新等）中重复验证逻辑。
窥视卡
雷达卡
发表于 2013-3-31 14:11:59
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡