4

简而言之——在CLR 存储过程中实现大部分业务逻辑是否是一个好的设计解决方案？

我最近读了很多关于它们的文章，但我不知道什么时候应该使用它们，什么是最佳实践，它们是否足够好。

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

  • 解析一个固定长度的大文本文件，
  • 从文件的每一行中提取一些数字，
  • 根据这些数字应用一些复杂的业务规则（涉及正则表达式匹配、与数据库中许多表中的数据进行模式匹配等），
  • 并且作为这个计算更新数据库中的记录的结果。

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

此应用程序似乎是实现经典 3 层架构的理想选择：数据层、逻辑层和 GUI 层。

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

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

优点：

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

缺点：

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

我想听听您对 SQL CLR 的所有意见。有人在生产中使用它吗？这样的设计有问题吗？这是一件好事吗？

4

3 回答 3

4

我不这样做 - CLR ins SQL Server 对很多事情都非常有用（计算哈希，执行 SQL 刚刚吸收的字符串操作，正则表达式来验证字段值等），但是复杂的逻辑，恕我直言，在数据库中没有业务。

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

于 2010-05-20T15:03:58.417 回答
2

就我个人而言，我更喜欢拥有不依赖于数据库的业务功能。我只在需要高级数据查询时才使用 CLR 存储过程（以生成在 SQL 中不容易做到的格式）。取决于你在做什么，无论如何我倾向于使用标准存储过程获得更好的性能结果，所以我个人只将它们用于我的高级任务。

我的两分钱。

HTH。

于 2010-05-20T15:04:39.340 回答
2

通常，您可能不想这样做，除非您可以获得显着的性能优势或有令人信服的技术理由这样做。这种原因的一个例子可能是自定义聚合函数。

使用 CLR 存储过程的一些充分理由：

  • 您可以受益于该技术的独特功能，例如自定义聚合函数。

  • 您可以从 CLR Sproc 中获得性能优势——也许是一个快速的逐记录处理任务，您可以从快进游标中读取，在核心中缓冲输出并将其批量加载到目标表中。

  • 您想要包装一些 .Net 代码或 .Net 库，并使其可用于在数据库服务器上运行的 SQL 代码。这方面的一个例子可能是 OP 问题中的正则表达式匹配器。

  • 你想欺骗和包装一些非托管和非常不安全的东西，以便在不使用 XP 的情况下从 SQL 代码访问它。从技术上讲，微软已经声明 XP 已被弃用，许多安装出于安全原因禁用了它们。

    有时您无法选择更改客户端代码（也许您有一个现成的应用程序），因此您可能需要从数据库中启动外部操作。在这种情况下，您可能需要让触发器或存储过程与外界交互，可能需要查询工作流的状态，将某些内容写入文件系统，或者（更极端地）通过屏幕将事务发布到远程大型机系统刮刀库。

使用 CLR 存储过程的坏理由：

  • 对通常在中间层完成的事情进行了较小的性能改进。请注意，磁盘流量可能比网络流量慢得多，除非您尝试通过网络连接流式传输大量数据。

  • CLR 存储过程很酷，你想把它们放在你的简历上

  • 无法编写面向集合的 SQL。

于 2010-05-20T15:18:20.010 回答