关于扩展存储过程的思考答案

【问题标题】：Thoughts On Extended Stored Procedures关于扩展存储过程的思考
【发布时间】：2010-02-19 14:25:20
【问题描述】：

我希望使用 SQL Server 或任何其他 RDBMS 中不可用的功能和逻辑在数据库中插入和更新记录。今天早上谷歌搜索了一下之后，我遇到了扩展存储过程的概念。据我所知，我应该能够将我想要的功能编译到一个 dll 中，使用该 dll 创建一个存储过程来进行插入/更新。

但是，我遇到的大多数文章和示例都有些过时（~2000 年）。扩展存储过程仍然是可接受的做法吗？我远非该领域的专家，因此任何其他建议或 cmets 将不胜感激。

【问题讨论】：

我很好奇 MSSSQL 或任何其他 RDMBS 中没有哪种逻辑。是不可用的特定库吗？您还看过哪些其他 RDMBS？甲骨文？ DB2? Postgres？
@FrustratedWithFormsDesigner - 典型的事情（至少在 SQL Server 中）是正则表达式。在 .NET 中很简单，但在 SQL Server 中没有内置支持
只是好奇 - 为什么您希望该逻辑存在于数据库中？
@AdaTheDev：不支持正则表达式？我想我应该感谢 Oracle 有一些正则表达式支持（虽然可能很糟糕，但我仍然可以完成我需要做的所有事情）。

【解决方案1】：

如果您使用的是 SQL Server 2005 或更高版本，SQL CLR 是值得关注的领域。您可以从 SQL Server 中调用 .NET 代码。

MSDN 上的This 文章是一个不错的起点。

【讨论】：

【解决方案2】：

扩展存储过程是否仍然存在可接受的做法？

不，它们已被正式弃用，并将在未来的版本中停止使用。请参阅Deprecated Database Engine Features in SQL Server 2008，在 SQL Server 的未来版本中不支持的功能 表中：

【讨论】：

【解决方案3】：

我通常建议不要使用 CLR 过程，在大多数情况下，您可以将面临的问题重构为 Transact Sql 可以处理的问题。当关系数据库在执行基于集合的操作时表现最佳时，最值得关注的是通常伴随使用 CLR 过程的过程方法。

所以我总是问的第一个问题是，无论如何要将问题重构为基于集合的操作。

如果不是，那我问你为什么要在数据库服务器内部执行代码，而不是在应用层？考虑将逻辑放在数据库中可能对性能产生的影响。（如果您的数据库服务器有足够的额外处理时间，这可能不是问题）。

如果您确实使用 CLR 过程，我认为它们最适合用于密集计算和复杂逻辑。

【讨论】：