sql-server - SQL Server CLR 存储过程在数据处理任务中——是好还是坏？

Question

简而言之 - 实现 CLR stored procedures 中的大部分业务逻辑是一个很好的设计解决方案吗？ ？

我最近阅读了很多有关它们的内容，但我不知道何时应该使用它们，最佳实践是什么，它们是否足够好。

例如，我的业务应用程序需要

• 解析一个大的fixed-length text file ,
• 从文件的每一行中提取一些数字，
• 根据这些数字应用一些复杂的业务规则(涉及正则表达式匹配、针对数据库中许多表中的数据进行模式匹配等)，
• 并作为此计算的结果更新数据库中的记录。

还有一个 GUI 可供用户选择文件、查看结果等。

该应用程序似乎是实现经典三层架构的良好候选者:数据层、逻辑层和 GUI 层。

• 数据层将访问数据库
• 逻辑层将作为 WCF 服务运行并实现业务规则，与数据层交互
• GUI 层将是逻辑层和用户之间的通信手段。

现在，考虑到这种设计，我可以看到大多数业务规则可能在 SQL CLR 中实现并存储在 SQL Server 中。我可能会将所有原始数据存储在数据库中，在那里运行处理并获取结果。我看到了这个解决方案的一些优点和缺点:

优点:

• 业务逻辑靠近数据运行，这意味着网络流量更少。
• 一次处理所有数据，可能利用并行化和最佳执行计划。

缺点:

• 业务逻辑分散:有些部分在这里，有些部分在那里。
• 有问题的设计方案，可能会遇到未知的问题。
• 难以实现处理任务的进度指示器。

我想听听您对 SQL CLR 的所有看法。有人在生产中使用它吗？这样的设计有什么问题吗？这是好事吗？

Answer 1

我不这样做 - SQL Server 中的 CLR 非常适合做很多事情(计算哈希、执行 SQL 刚刚吸收的字符串操作、正则表达式来验证字段值等)，但复杂的逻辑，恕我直言，没有什么用处。数据库。

这是单点性能问题，而且扩展起来也非常昂贵。另外，要么我把它全部放在那里，要么 - 好吧 - 我在维护方面遇到了严重的问题。