CLR存储过程是否优于SQL 2005+中的TSQL存储过程？

我当前的观点是否定的,更喜欢Transact SQL存储过程,因为它们的重量较轻且(可能)性能更高,而CLR程序允许开发人员应对各种恶作剧.

但是最近我需要调试一些写得很差的TSQL存储过程.像往常一样,我发现许多问题是由于原始开发人员开发人员没有真正的TSQL经验,他们是以ASP.NET/C#为重点.

因此,使用CLR过程首先会为这类开发人员提供更熟悉的工具集,其次,调试和测试工具更强大(即Visual Studio而不是SQL Management Studio).

我很想听听你的经历,因为它似乎不是一个简单的选择.

有很好的写作,经过深思熟虑的T-SQL和CLR.如果某些函数没有经常调用,并且在SQL Server 2000中需要扩展过程,则CLR可能是一个选项.此外,在数据旁边运行计算等操作可能会很吸引人.但是通过投入新技术来解决糟糕的程序员听起来像个坏主意.

CLR存储过程并不意味着替换基于集合的查询.如果需要查询数据库,您仍然需要将SQL放入CLR代码中,就像它嵌入在常规代码中一样.这将是浪费精力.

CLR存储过程主要用于两个方面:1)与OS的交互,例如从文件读取或在MSMQ中删除消息,以及2)执行复杂计算,尤其是当您已经使用.NET语言编写代码时做计算.

在SQL Server中托管CLR旨在为数据库开发人员提供更灵活的选项,帮助他们完成任务.与其他人提到的一样,SQL非常适合对数据集进行操作和修改.任何使用复杂的业务/域规则进行广泛的大型应用程序开发的人都可能会告诉您 - 尝试使用纯SQL(有时在单个宏查询中)执行其中一些规则可能会变得真正的噩梦.

只有某些任务可以以程序或OO方式更好地处理.通过选择使用.NET代码来分解逻辑序列,查询操作可以更容易地读取和调试.使用CLR存储过程后,我可以告诉您逐步使用调试器确实可以更容易地完成数据库级别的操作.

仅举一个例子,我们经常在这里使用CLR存储过程作为动态搜索查询的"网关".说一个搜索请求,最多可以有30个不同的搜索参数.用户显然不会使用全部30个,因此传入的数据结构将包含30个参数,但主要是DBNULL.出于明显的安全原因,客户端无法生成动态语句.生成的动态语句在内部生成,无需担心外部"额外".