先看看怎么写SQL2005中的托管程序：
[SqlFunction(DataAccess = DataAccessKind.Read)]
public static string ReportSqlVersion()
{
SqlCommand cmd = SqlContext.GetCommand();
cmd.CommandText = "select @@version";
return (string)cmd.ExecuteScalar();
}
上面是最简单的返回版本号的Function. 和ADO.net一样，通过Command执行查询。看看System.Data.SqlServer.SqlCommand的定义：
public sealed class SqlCommand : System.Data.Sql.ISqlCommand, System.Data.IDbCommand, System.IDisposable
居然也实现了System.Data.IDbCommand!
另外一个向客户端返回结果集的方法：
ISqlReader rdr = cmd.ExecuteReader();
SqlContext.GetPipe().Send(rdr);
看起来SQL2005中的托管程序没什么不同，只是通过System.Data.SqlServer包来读取数据库。
如果把T-SQL变成托管代码执行，然后把数据接力给外部的APP程序，看起来很罗嗦。
以前写SP的主要理由是性能，现在用了CLR之后性能大打折扣，那SQL2005中加入CLR的理由是什么呢？
我能想到的理由，欢迎各位补充：
1. 语言的通用性，抛弃蹩脚的T-SQL
2. 语言的功能（比如错误处理）
3. 动态调试
4. 利用辅助工具包，大量API
5. 把原有中间层业务逻辑全部转移到SP中（中小应用），(可选)发布成WS
缺点：
1. 负载扩充不容易
2. 瓶颈分析有困难
以后WebApp中不需要业务层封装，直接调用SP。
用Oracle也能用Java写SP封装业务逻辑，但是SQL2005中还能把他们直接发布成WS，跟SmartClient真是绝配。