将流程函数中的 C# 迁移到 SQL Server CLR 函数
从进程内 C# 代码迁移到 SQL CLR 函数有哪些限制、意外陷阱和性能特征？
目前，我们有几个数据密集型进程，使用进程中 C# Asp.net MVC 项目运行得非常快，根本不使用数据库。性能非常重要。该应用程序使用静态内存缓存并执行复杂的操作以获得最终结果。缓存更新有点麻烦，我们正在考虑将其中一些进程转移到 SQL Server 查询，这些查询只会输出最终结果，以便在 C# 应用程序级别需要更少的数据缓存。该过程很复杂，而且我们知道迁移到数据库需要大量使用 SQL Server CLR 函数。
我们看到利用数据库有很多优势，但由于需要使用 CLR 函数，因此暂停了以下几个原因：
没有 Azure： SQL CLR 函数Azure 不支持，
测试成本高 SQL CLR 函数可能会比较慢，并且测试需要大量工作
小用户群：经过一小时的谷歌搜索后发现，CLR 函数的使用有些不常见，这使得社区支持（以及可能的 MS 支持）成为一个问题。
我很想听听将 C# 应用程序从进程中迁移到 CLR 函数的人的来信。
在您的答案中，请假设需要自定义 SQL CLR 函数。
What are the limitations, unexpected pitfalls and performance traits of moving from in process C# code to SQL CLR Functions?
We currently have several data heavy processes that run very fast using in process C# Asp.net MVC project without using a db at all. Performance is very important. The application uses a static in memory cache and performs complex operations to arrive at a final result. Cache updating is a bit of a pain and we are considering moving some of these processes to SQL Server queries that would just output the final result so that less data caching is needed at the c# app level. The processes are complex and we know that moving to the database would require extensive use of SQL Server CLR functions.
We see a lot of advantages in leveraging the database, but the required use of CLR functions gives pause for a few reasons:
No Azure: SQL CLR functions are not supported by Azure,
High Testing Cost: the SQL CLR functions could be slower and testing will take significant work
Small User Base: An hour of googling reveals that use of CLR functions is somewhat uncommon which makes community support (and possible MS support) a concern.
I would love to hear from someone who has moved a C# app from in process to CLR functions.
In your answers please assume that custom SQL CLR functions are required.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
使用 Sql Server CLR 函数，您的
过程要困难得多 – 我认为您应该尽可能自动化这一过程。
每次您希望更新功能时，您可能还需要获得 DBA 的同意。
然而，在说过“将代码带入数据”之后，有时仍然是一个非常好的选择。
Your
Process is a lot harder with Sql Server CLR functions – I think you should automate as much of this as possible.
You may also need to get the agreement of a DBA every time you wished to update a function.
However after saying that “take your code to your data” can still be a very good option at times.
如果您自己安装 SQLServer 并像在本地一样单独对其进行许可，那么您也许可以在 Azure 中执行此操作，而不是采用其托管 SQLServer 环境选项以及包含 SQLServer 即服务的增量费用。但是，接下来配置所有其他支持数据库的基础设施（备份、HA 等）就由您来完成了。
You might be able to do it in Azure if you install SQLServer yourself and license it separately like it was on-premise, rather than taking their managed SQLServer environment options with the incremental upcharge for including SQLServer-as-a-service. But then configuring all the other infrastructure around supporting the database would be on you (backups, HA, etc.)