3

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

一个存储过程可以动态创建另一个存储过程吗?(我个人对 SQL Server 2008 很感兴趣,但为了更广泛的讨论,将其保持开放)

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

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

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

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

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

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

[编辑]

我在研究中发现的这篇博文描述了我所看到的相同问题。如果有人能指出我或博客海报可能做错导致开销的事情,我会很高兴。

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

4

1 回答 1

0

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

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

于 2009-08-05T08:29:26.987 回答