Sql server 如何利用CLR代替T-SQL函数来避免RBAR？

我需要在一些SQL Server数据集上重复执行一些简单的函数，如heavisides、binary step、sigmoid和各种切线。我经常听说，通过T-SQL派生此类函数中使用的任何集合和聚合都是有效的，但在T-SQL中重复执行此类函数则效率低下。据我所知，根据SQL Server大师Jeff Moden的流行术语，使用T-SQL来实现这一目的显然符合RBAR操作的条件，或者说是逐行操作。在散布在互联网上的各种文章中，我经常读到这样的函数应该用C或VB.Net来实现，但我不清楚如何才能做到这一点，并且仍然避免RBAR。有人能告诉我一些使用.Net语言实现这一目的的最佳实践吗？这引发了一些密切相关的问题，如：

1我可以在CLR函数中有效地执行此操作吗

2在这样的函数中使用C或VB.Net数组并向它们提供整套数据会更有效吗

3如果我仍然为集合中的每个记录调用一次CLR函数，就像对普通SQL Server函数调用一样，那么在这种设计中如何避免RBAR

4是否应该在中间层对象中捕获此类逻辑，并通过网络提供数据

5如果我不得不整天偶尔批量执行这些功能，我可以在服务器端运行一个C或VB.net程序，然后不断地向它提供数据吗？此解决方案可能与2配合使用，但我认为如果允许在SQL server控制之外消耗太多内存/CPU/IO，可能会损害服务器的稳定性

---

这些问题的主旨主要针对一个目标：在执行这些功能时找到避免RBAR的最有效方法。如果我没有提到其他一些避免它们的方法，请告诉我。我已经知道如何通过使用T-SQL创建聚合和基于集合的解决方案来避免一些RBAR，但我想知道是否可以消除与重复函数调用直接相关的任何其他RBAR。最佳实践似乎是使用.Net而不是SQL Server函数来实现这一点，但我不清楚如何在实践中实现这一点。如果能帮我澄清这个设计决策，我们将不胜感激。

不。CLR只是一个用.Net编写并在SQL Server中公开的函数，因此SQL引擎可以调用它。它们的效率通常低于优化的SQL查询，但允许您执行SQL无法执行的操作，如高级字符串操作或分析计算。作为一个副作用，CLR允许web程序员在SQL不熟悉时创建有意义的代码，但也避免了SQL基于集合的非RBAR高效操作

如果您的计算是在整个数据集上进行的，比如在squirrel数据库中查找平均squirrel权重，那么您可以使用基于集合的聚合从dbo.squirres获取CLR函数SELECT AVG[weight]的输入，但是如果您需要对数据中的每一行进行计算，那么如果SQL无法进行计算，您就有点卡住了

如果可以使用SQL执行计算，则应创建一个执行计算的内联表值函数，然后使用外部应用更新计算字段。如果你想了解这条路线，这里有一个解释。

---

分析函数是罪魁祸首。你不能使用表格功能吗？转换和转换是每行运行多个查询的小成本。你确定这仍然是一个关系问题吗？然后使用SQL。如果这是草书，则使用适当的方法，如.Net，尽管SQL有自己的方法。我想我不明白你怎么会有简单的计算如果你说的是真的是的，它肯定是相关的，因为我必须先推导出一些复杂的集合，然后再应用这些简单的数学函数，比如各种阶跃函数和sigmoid函数，例如逻辑函数-参见每一行。我不使用表格函数的原因是，我仍然需要为其中的每一行执行一次数学函数，所以这对我来说根本没有帮助。我可以很容易地用T-SQL编写我自己的逻辑函数，但我听说用C或VB.Net编写这种函数会更有效。我可能会感到困惑。我指的是关系数据集。集合论。T-SQL确实有包括XQuery在内的草书操作。OPENXML使用集合，但是是的，使用草书语言处理草书逻辑可能更有效。您能给出其中一个函数的示例吗，比如，特别是在伪代码或其他代码中？如果只需要在一组字段上运行算术运算，通常可以内联完成，这意味着SQL可以用适当的代码替换函数，而不必在每一行上完全执行函数。如果您有比这复杂得多的东西，那么CLR可能是wo

---

我在考虑。但是，请记住，CLR带来了一系列的问题和潜在的安全问题，这些问题可能很难完全解释或通过DBA。至于CLR是否比t-sql快的单一问题，这取决于具体情况，您必须通过测试来解决。通过CRL，8k ascii或4k unicode下的经典字符串拆分速度要快得多，实在不值得。在sql 2016之前解析大型JSON字符串是值得的。如果性能很重要，请花时间同时执行这两项操作，并将结果与具有实际值的大型数据集进行比较。