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


当前回答

函数可以在选择语句中使用,而过程则不能。 存储过程同时接受输入和输出参数,而函数只接受输入参数。 函数不能返回text, ntext, image和时间戳类型的值,而过程可以。 函数可以在创建表中作为用户定义的数据类型使用,但过程不能。

***例如:-create table <tablename>(name varchar(10),salary getsal(name))

这里getsal是一个用户定义的函数,它返回一个工资类型,当创建表时,没有存储空间分配给工资类型,getsal函数也不执行,但当我们从这个表中获取一些值时,getsal函数get被执行,返回 类型作为结果集返回。

其他回答

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

函数可以是…

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

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

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

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


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

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

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

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

基本区别

函数必须返回一个值,但在存储过程中它是可选的(过程可以返回零或n个值)。

函数只能有输入参数,而过程可以有输入/输出参数。

函数需要一个输入参数,这是必须的,但存储过程可能需要o到n个输入参数。

函数可以从过程中调用,而过程不能从函数中调用。

之前的区别

Procedure允许在其中使用SELECT和DML(INSERT/UPDATE/DELETE)语句,而Function只允许在其中使用SELECT语句。

过程不能在SELECT语句中使用,而Function可以嵌入到SELECT语句中。

存储过程不能在WHERE/HAVING/SELECT部分的SQL语句中使用,而函数可以。

返回表的函数可以被视为另一个行集。这可以在与其他表的join中使用。

内联函数可以被认为是接受参数的视图,可以在join和其他行集操作中使用。

异常可以用try-catch块在过程中处理,而try-catch块不能在函数中使用。

我们可以在过程中使用事务管理,而不能在功能中使用。

函数是计算值,不能对SQL Server执行永久的环境更改(即不允许INSERT或UPDATE语句)。

如果函数返回标量值,则可以在SQL语句中使用它;如果函数返回结果集,则可以连接它。

从总结答案的评论中,有一点值得注意。感谢@Sean K Anderson:

函数遵循计算机科学的定义,即它们必须返回一个值,并且不能更改作为参数接收的数据 (论点)。函数不允许改变任何东西,必须 至少有一个参数,并且它们必须返回一个值。存储 Procs不需要有参数,可以改变数据库对象, 并且不需要返回值。

STORE PROCEDURE FUNCTION (USER DEFINED FUNCTION)
Procedure can return 0, single or multiple values Function can return only single value
Procedure can have input, output parameters Function can have only input parameters
Procedure cannot be called from a function Functions can be called from procedure
Procedure allows select as well as DML statement in it Function allows only select statement in it
Exception can be handled by try-catch block in a procedure Try-catch block cannot be used in a function
We can go for transaction management in procedure We can not go for transaction management in function
Procedure cannot be utilized in a select statement Function can be embedded in a select statement
Procedure can affect the state of database means it can perform CRUD operation on database Function can not affect the state of database means it can not perform CRUD operation on database
Procedure can use temporary tables Function can not use temporary tables
Procedure can alter the server environment parameters Function can not alter the environment parameters
Procedure can use when we want instead is to group a possibly- complex set of SQL statements Function can use when we want to compute and return a value for use in other SQL statements