我应该使用SQL CLR函数中的EF6吗

本文关键字：EF6 函数 CLR SQL 我应该 | 更新日期: 2023-09-27 18:28:07

我的任务是研究一些复杂的计算代码（C#），并将其转换为SQL Server 2012上的CLR函数。计算的复杂性意味着将其作为经典的SQL SP或UDF编写是不可行的，因此使用CLR的想法是存在的，并且经过了测试。

我遇到的问题是，计算使用了一个使用EF6的数据层。显然，我会为CLR函数提取尽可能小的一部分现有代码，但我仍然必须满足所有的依赖关系。

我的问题不是我该如何做到这一点[稍后会出现：）]，而是应该我做这一点？不知怎的，把整个EF塞进我将要访问的数据库中进行计算，感觉是错误的——感觉非常臃肿。

请提出意见、建议、想法？

感谢

我应该使用SQL CLR函数中的EF6吗

除非有非常的压力，并且特别需要保持应用层和这个SQLCLR函数之间的代码库同步，否则我会说：

没有。这样做似乎没有什么好处。应该只需要几个数据点，这些数据点很容易通过简单的SqlConnection使用Context Connection = true;作为连接字符串（即进程内连接）来获取。

而且，考虑到性能是一个问题（无论如何都应该如此，但仍然如此），因此从一开始就走这条SQLCLR路径的原因是，添加一层又一层的代码似乎会适得其反，因为这些代码允许使用实体框架的易用抽象层。

此外，为什么要从函数中获取数据，而不是将其传递到函数中？是否有传入的值需要根据其特定值进行额外查找？通过将标量函数构造为确定性的，您将获得相当多的性能：

  1. 在SqlFunction属性中标记为IsDeterministic = true的标量SQLCLR函数的输出被缓存并映射到输入参数，这样它们就可以被查找（在同一查询中其他行的上下文中）并重新使用，而不是再次运行该函数

  2. 并行计划中允许在SqlFunction属性中标记为IsDeterministic = true、AND而非标记为DataAccess = DataAccessKind.Read的标量SQLCLR函数。如果IsDeterministic被而不是标记为true，或者DataAccess（甚至SystemDataAccess）被标记为Read，那么它们将像常规T-SQL函数一样工作，因为它们将阻止任何使用它们的查询获得并行执行计划。

相关文章：