Functions vs Stored Procedures

Question

Let\'s say I have to implement a piece of T-SQL code that must return a table as result. I can implement a table-valued function or else a stored procedure that returns a se

Answer 1

1. Procedure can return zero or n values whereas function can return one value which is mandatory.

2. Procedures can have input/output parameters for it whereas functions can have only input parameters.

3. Procedure allows select as well as DML statement in it whereas function allows only select statement in it.

4. Functions can be called from procedure whereas procedures cannot be called from function.

5. Exception can be handled by try-catch block in a procedure whereas try-catch block cannot be used in a function.

6. We can go for transaction management in procedure whereas we can't go in function.

7. Procedures can not be utilized in a select statement whereas function can be embedded in a select statement.

8. UDF (User Defined function) can be used in the SQL statements anywhere in the WHERE/HAVING/SELECT section whereas stored procedures cannot be.

9. UDFs that return tables can be treated as another rowset. This can be used in JOINs with other tables.

10. Inline UDFs can be though of as views that take parameters and can be used in JOINs and other rowset operations.

Answer 2

I ran some tests with a long running bit of logic, with the same bit of code (a long SELECT statement) running in both a Table Valued Function and a Stored Procedure, and a straight EXEC/SELECT, and each performed identically.

In my opinion always use a Table Valued Function rather than a stored procedure to return a result set, as it makes logic much easier and readable in queries that subsequently join to them, and enables you to reuse the same logic. To avoid too much of a performance hit, I often use "optional" parameters (i.e. you can pass NULL to them) to enable the function to return the result set to be quicker, e.g.:

CREATE FUNCTION dbo.getSitePermissions(@RegionID int, @optPersonID int, optSiteID int)
AS
RETURN 
    SELECT DISTINCT SiteID, PersonID
    FROM dbo.SiteViewPermissions
    WHERE (@optPersonID IS NULL OR @optPersonID = PersonID)
    AND (@optSiteID IS NULL OR @optSiteID = SiteID)
    AND @RegionID = RegionID

This way you can use this function for many different situations, and don't take a huge performance hit. I believe this is more efficient than filtering afterwards:

SELECT * FROM dbo.getSitePermissions(@RegionID) WHERE SiteID = 1

I have used this technique in several functions, sometimes with a long list of "optional" parameters of this type.

Answer 3

If you have a function you could use it as a part of your SQL statement, for example

SELECT function_name(field1) FROM table

It does not work this way for the stored procedures.

Answer 4

Functions must be deterministic, and cannot be used to make changes to the database, whereas stored procedures allow you to do inserts and updates, etc.

You should limit your use of functions, since they pose a huge scalability problem for big, complex queries. They become sort of a "black box" for the query optimizer, and you'll see enormous differences in performance between using functions and simply inserting the code into a query.

But they are definitely useful for table-valued returns in very specific cases.

If you need to parse a comma-delimited list, to simulate passing an array to a procedure, a function can turn the list into a table for you. This is common practice with Sql Server 2005, since we can't pass in tables to stored procedures yet (we can with 2008).

Answer 5

From the docs:

If a stored procedure meets the following criteria, it is a good candidate for being rewritten as a table-valued function:

• The logic is expressible in a single SELECT statement but is a stored procedure, rather than a view, only because of the need for parameters.

• The stored procedure does not perform update operations, except to table variables.

• There is no need for dynamic EXECUTE statements.

• The stored procedure returns one result set.

• The primary purpose of the stored procedure is to build intermediate results that are to be loaded into a temporary table, which is then queried in a SELECT statement.

Answer 6

If you're likely to want to combine the result of this piece of code with other tables, then obviously a table-valued function will allow you to compose the results in a single SELECT statement.

Generally, there's a hierarchy (View < TV Function < Stored Proc). You can do more in each one, but the ability to compose the outputs, and for the optimizer to get really involved decreases as the functionality increases.

So use whichever one minimally allows you to express your desired result.