Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Chapter 13: User-Defined Functions
418
To simplify things a bit, we’ll encapsulate everything in a function instead:
USE AdventureWorks2008;
GO
CREATE FUNCTION dbo.fnContactSearch(@LastName nvarchar(50))
RETURNS TABLE
AS
RETURN (SELECT p.BusinessEntityID,
LastName + ‘, ‘ + FirstName AS Name,
ea.EmailAddress
FROM Person.Person as p
LEFT OUTER JOIN Person.EmailAddress ea
ON ea.BusinessEntityID = p.BusinessEntityID
WHERE LastName Like @LastName + ‘%’);
GO
Now we’re set up pretty well — to execute it, we just call the function and provide the parameter:
SELECT *
FROM fnContactSearch(‘Ad’);
And we get back the same result set — no WHERE clause, no filtering the SELECT list, and, as our friends
down under would say, no worries; we can use this over and over again without having to use the old
cut-and-paste trick. Note, also, that while you could have achieved similar results with a sproc and an
EXEC command, you couldn’t directly join the results of the sproc to another table.
Well, all this would probably be exciting enough, but sometimes we need more than just a single SELECT
statement. Sometimes, we want more than just a parameterized view. Indeed, much as we saw with some
of our scalar functions, we may need to execute multiple statements in order to achieve the results that
we want. User-defined functions support this notion just fine. Indeed, they can return tables that are created
using multiple statements — the only big difference when using multiple statements is that you
must both name and define the metadata (much as you would for a temporary table) for what you’ll be
returning.
To illustrate this example, we’ll discuss a very common problem in the relational database world —
hierarchical data.
Imagine for a moment that you are working in the human resources department. You have an Employee
table, and it has a unary relationship (a foreign key that relates to another column in the same table) that
relates employees to their bosses through the ManagerID column — that is, the way you know who is
someone’s boss, is by relating the ManagerID column back to another EmployeeID. A very common need
in a scenario like this is to be able to create a reporting tree — that is, a list of all of the people who exist
below a given manager in an organization chart.
Historically, relational databases had a major weakness in dealing with hierarchical data. Numerous
articles, white papers, and books have been written on this subject. Fortunately for us, SQL Server 2008
introduces a new methodology for dealing with hierarchical data. The newly introduced features are the
hierarchyID data type and a collection of built-in functions to help deal with tree type data structures