SQL Server 2008 的 CLR 程序集有哪些限制?

发布于 2024-10-15 22:03:16 字数 373 浏览 2 评论 0原文


我正在计划一些计算量相当大的报告,我认为最好将其传输到加载到 Microsoft SQL Server 的自定义 .NET 程序集。使用此功能的公司只会使用 SQL Server Enterprise 版本,因此功能支持没有问题。

问题是:
这实际上是个好主意吗?
我想导出此功能,因为我希望能够使用以下功能:

  • 多线程(线程数将是处理的实体之间的最小值,以及配置文件中设置的最大数。我不知道任何其他我应该指定上限。)
  • 非托管代​​码(用于流处理的 C++ 库)
  • 有时甚至是 COM 互操作或 shell 命令,尽管这种情况不太可能发生。

他们会工作得很好吗?就我的情况而言,我应该了解什么限制吗?

I am planning some reports with quite a heavy load of calculations, which I thought is better to transfer to a custom .NET assembly loaded to Microsoft SQL Server. The companies who will use this will only use SQL Server Enterprise editions, so no problem with feature support.

The question is:
Is it actually a good idea?
I want to export this functionality because I want to be able to use features like:

  • Multi-threading (the number of threads will be the minimum between the processed entities, and the maximum number set in configuration file. I don't know any other upper limit I should specify.)
  • Unmanaged code (C++ libraries for stream processing)
  • Sometimes even COM Interop or shell commands, though this is less likely.

Will they work fine? Are there any limitations I should know about, in my case?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

勿忘心安 2024-10-22 22:03:16

您列出的所有内容都是可能的,但有一些限制。主机保护属性允许访问创建线程,但禁止访问 Thread.Join 等。在 msdn

现在的问题是“你应该这样做吗”?我认为这种方法不太合理,因为它会给数据库服务器带来很大的处理负载,如果需要的话,这将很难扩展。我认为更好的方法是将自定义程序集添加到 SQL Server Reporting Services 并让处理在那里进行。如果遇到可扩展性问题,可以添加额外的报告服务计算机。

方法和内容也没有限制。 Reporting Services 中加载的程序集中的类。

Everything you list is possible with some limitations. The Host Protection Attributes allow access to create threads, but prohibit access to Thread.Join etc. Read more about it on msdn

Now the question is "Should you do this"? I think the approach is not very sound as it will put a big processing load on your database server which will be very hard to scale if needed. I think a better approach is to add a Custom assembly to SQL Server Reporting Services and let the processing happen over there. If you run into scalability issues an additional reporting services machine can be added.

There are also no restrictions on methods & classes in assemblies loaded in Reporting Services.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文