在SQL中什么时候应该使用函数而不是存储过程,反之亦然?每一个的目的是什么?


当前回答

下面是一个总结差异的表格:

Stored Procedure Function
Returns Zero or more values A single value (which may be a scalar or a table)
Can use transaction? Yes No
Can output to parameters? Yes No
Can call each other? Can call a function Cannot call a stored procedure
Usable in SELECT, WHERE and HAVING statements? No Yes
Supports exception handling (via try/catch)? Yes No

其他回答

这里有一个更喜欢函数而不是存储过程的实际原因。如果有一个存储过程需要另一个存储过程的结果,则必须使用insert-exec语句。这意味着您必须创建一个临时表并使用exec语句将存储过程的结果插入到临时表中。它是混乱的。这样做的一个问题是insert-execs不能嵌套。

如果您使用调用其他存储过程的存储过程,可能会遇到这种情况。如果嵌套存储过程只是返回一个数据集,则可以将其替换为表值函数,这样就不会再出现此错误。

(这是我们应该将业务逻辑排除在数据库之外的另一个原因)

我知道这是一个非常老的问题,但是我在任何答案中都没有看到一个关键的方面:内联到查询计划中。

函数可以是…

标量: 创建函数…返回scalar_type AS BEGIN…结束 Multi-statement表值: 创建函数…返回@r表(…)开始…结束 内联表值: 创建函数…返回表作为return select…

第三种(内联表值)被查询优化器本质上视为(参数化)视图,这意味着从查询中引用函数类似于复制粘贴函数的SQL主体(而不是实际的复制粘贴),导致以下好处:

查询计划器可以优化内联函数的执行,就像它会优化任何其他子查询一样(例如,消除未使用的列,下推谓词,选择不同的JOIN策略等)。 组合几个内联函数并不需要在将第一个函数的结果提供给下一个函数之前实现它。

上述方法可能会带来潜在的显著性能节省,特别是在组合多个级别的功能时。


注意:看起来SQL Server 2019也将引入某种形式的标量函数内联。

用户定义函数是sql server程序员可用的重要工具。您可以像这样在SQL语句中内联使用它

SELECT a, lookupValue(b), c FROM customers 

其中lookupValue将是UDF。这种功能在使用存储过程时是不可能实现的。同时,您不能在UDF中做某些事情。这里要记住的基本事情是UDF的:

不能产生永久的变化 无法更改数据

存储过程可以做这些事情。

对我来说,UDF的内联使用是UDF最重要的使用。

下面是一个总结差异的表格:

Stored Procedure Function
Returns Zero or more values A single value (which may be a scalar or a table)
Can use transaction? Yes No
Can output to parameters? Yes No
Can call each other? Can call a function Cannot call a stored procedure
Usable in SELECT, WHERE and HAVING statements? No Yes
Supports exception handling (via try/catch)? Yes No

要决定何时使用以下几点可能会有所帮助-

存储过程不能返回表变量,而函数可以这样做。 您可以使用存储过程来更改服务器环境参数,而使用函数则不能。

干杯