当我们在 UDF 中规避 SQL Server 对副作用操作的限制时，会面临什么风险？

Question

今天，我在此答案中使用了该方法，以在同一数据库架构的多个实例中替换名称，保险号和地址，取决于"测试"/数据中的"生产"标志。

背景：尝试做

CREATE FUNCTION dbo.FailsToCreate() 
RETURNS uniqueidentifier 
AS 
BEGIN 
  RETURN NEWID()
END

不可避免地会失败

msg 443，级别16，状态1，过程失败 - 夸张，第6行[批次开始行27] 在功能中使用副作用操作员" newid"的使用无效。

现在我们可以做得足够

CREATE VIEW dbo.vwGuessWhat AS SELECT NEWID() Fooled

令人惊讶地使我们能够与

一起使用

CREATE FUNCTION dbo.SuddenlyWorks() 
RETURNS uniqueidentifier 
AS 
BEGIN 
  RETURN (SELECT Fooled FROM vwGuessWhat)
END

文档对后果保持沉默。它仅列出了无法使用的功能，也没有提及绕过限制的可能性。

我可以在生产代码中安全地使用这种方法，还是绕过SQL Server的验证会导致其故障？

Answer 1

本身没有风险。您提出了一种有趣的方法来规避SQL函数的限制。

单独的注意，标量UDF的众多问题之一是它们杀死了并行性。换句话说，即使您使用Adam Machanic的sake_parallel（）或TraceFlag8649。

如果您想要一个并行计划，则需要使dbo.suddenlyworks（）inline表值函数。