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

Question

这将是一个直接的问题和一个讨论点。我先问直接的问题：

一个存储过程可以动态创建另一个存储过程吗？ （就我个人而言，我对 SQL Server 2008 很感兴趣，但为了更广泛的讨论，将其保持开放状态）

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

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

一种解决方法是改用表值 UDF - 但是这些会使客户端代码复杂化，而您并不总是想要处理（尤其是当 UDF 只计算表达式的结果时）。

所以我最初的疯狂想法是使用 C 预处理器指令编写 proc，然后在提交给 RDBMS 之前将其传递给预处理器。这可能有效，但有其自身的问题。

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

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

[编辑]

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

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

Answer 1

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

至于你的想法，我真的看不出它有什么好处。像这样创建和删除对象可能是一项昂贵的操作，并且可能导致架构锁定。