sql - 使用存储过程进行元编程？

Question

这既是一个直接的问题，也是一个讨论点。我会先问直接的问题:

Can a stored procedure create another stored procedure dynamically? (Personally I'm interested in SQL Server 2008, but in the interests of wider discussion will leave it open)

现在我要问的原因。简而言之(您可以在其他地方阅读更多内容)，SQL Server 中的用户定义标量函数充其量是性能瓶颈。我在我们的代码库中看到了使总查询速度降低 3-4 倍的用法，但从我读到的内容来看，S-UDF 的本地影响可以达到 10 倍以上

然而，UDF 可能非常适合提高抽象级别、减少大量乏味的样板、集中逻辑规则等。在大多数情况下，它们归结为可以轻松内联扩展的简单表达式 - 但它们不是(我我真的只考虑非查询函数——例如字符串操作)。我已经看到一个错误报告，该错误报告将在未来的版本中解决——MS 的一些支持。但就目前而言，我们必须忍受(恕我直言)损坏的实现。

一种解决方法是改用表值 UDF - 然而，这些会使客户端代码以您并不总是希望处理的方式复杂化(尤其是当 UDF 仅计算表达式的结果时)。

所以一开始我的疯狂想法是用 C 预处理器指令编写 proc，然后在提交给 RDBMS 之前通过预处理器传递它。这可行，但有其自身的问题。

这让我想到了下一个疯狂的想法，即在数据库本身中定义“宏”，并有一个主进程接受一个包含未处理的带有宏的 SP 的字符串，内联扩展宏，然后将其提交到到 RDMS。这不是 SP 擅长的，但我认为它可以工作 - 假设你可以首先做到这一点 - 因此我最初的问题。

但是，现在我已经解释了我的问题路径，我还想留待其他想法。我敢肯定，我不是唯一一个一直在思考这些问题的人。也许已经有第三方解决方案了？我的谷歌搜索还没有出现太多。我还认为这将是一个有趣的讨论话题。

[编辑]

This blog post我在研究中发现描述了我所看到的相同问题。如果有人能指出我或博客发布者可能做错导致开销的事情，我会很高兴。

我还应该补充一点，我在我的 S-UDF 上使用了 WITH SCHEMABINDING，尽管它似乎没有给我任何优势

Answer 1

您的字符串处理 UDF 不会成为性能问题。标量 UDF 只有在它们执行选择并且对每一行都完成这些选择时才会成为问题。这反过来又激增了 IO。另一方面，字符串操作在内存中完成并且速度很快。

至于你的想法，我看不出有任何好处。像这样创建和删除对象可能是一项昂贵的操作，并可能导致模式锁定。