SQLCLR中的验证功能及其性能

Question

一旦插入新行，我就必须验证表中的所有数据行。

DETAILS：插入到表中的每一行都应该通过一组验证规则，并且这些规则可能根据行中的数据而有所不同。当用c#编写时，它看起来像小应用程序。因此，与其将其编写为单独的应用程序，我还计划将其编写为SQLCLR，以便很容易地调用这些SQLCLR编写的验证规则。

这是我第一次使用/探索SQLCLR，因此我担心性能会因此下降。我正在做一些事情，比如将c#应用程序转换为SQLCLR应用程序。

请用上面的场景向我建议sqlClr的性能。

提前谢谢

Answer 1

如果没有对数据进行验证的任何具体例子，这是一个非常普遍的问题，除了一个广义的建议之外，很难给出更多的内容。在这一点上，下面是有关SQLCLR (或Server中的CLR功能)和T的一些一般信息：

• 绝对不是这样的，直接的the总是比CLR例程执行同样的操作要快。to是一种数据语言，不一定最适合进行字符串操作或它具有功能的其他事情。我就这个问题发表了一篇关于简单对话的比较详细的分析：http://www.simple-talk.com/sql/t-sql-programming/clr-performance-testing/
• Data只能通过SQL检索或操作，因此，如果您也不打算在直接的T中进行速度不够快甚至不可能的计算，那么仅仅用.Net语言包装SELECT或DML语句就没有真正的好处。SQLCLR例程仍然需要打开数据库连接，以便与数据库对象(表、视图等)进行交互。即使您使用的是context_connection，如果代码在SqlCommand中只执行T-SQL，那么这是SQLCLR的错误设计/使用。
• SQLCLR不应该被看作是the的替代品。它需要作为一种工具来处理，它可以在某些地方帮助您，在这些地方，在tool中操作效率会降低，甚至不可能。有时可以通过使用sp_OACreate等来扩展功能，但这也有其自身的问题。我发现最好有一个中间地带，通过用户定义的函数和从that代码调用的存储过程，将在that中不容易、不可能或不高效的某些算法从.Net公开到that。为此，我创建了一个函数和过程库，称为SQL# (SQLsharp)，它大部分是免费的，可以在：

考虑到所有这些，你的情况是：

我必须在插入新行后立即验证表中的所有数据行。

..。

插入到表中的每一行都应通过一组验证规则，并且这些规则可能根据该行中的数据而有所不同。

听起来，它最适合在表中使用常规的the插入、更新触发器，该触发器使用的是直接the以及一些SQLCLR例程(取决于对“插入”表的特定验证)。同样，根据用于验证的具体算法，对于那些在CLR中做得更好的算法，将其中一些算法合并到单个.Net例程中可以获得一些效率，从而降低调用外部例程的启动成本。

当然，触发器是否最好取决于插入和更新的频率、正在执行的验证次数以及几年内表中的行数。如果DML频率很高，并且/或有很多行，那么可能采用断开连接的方法更好，但这不会改变关于如何实现验证算法的建议。如果验证将花费太长时间(您不希望延迟DML操作太长并导致阻塞)，则可以使用触发器将键值存储在单独的队列表中，SQL作业可以每隔几分钟处理一次，并决定是否保留。

正如我在一开始所说的那样，验证的示例将为您提供更好的建议，说明处理每个算法的最佳位置，但希望这些信息能够为您提供做出更好决策所需的信息。

记住，只有通过测试，您才能知道哪种方法对于任何特定的算法都更快！