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

So, as you can see, we can actually have very complex code build our table results for us, but it’s still a
table that results and, as such, it can be used just like any other table.
Understanding Determinism
Any coverage of UDFs would be incomplete without discussing determinism. If SQL Server is going to
build an index over something, it has to be able to deterministically define (define with certainty) what
the item being indexed is. Why does this matter to functions? Well, because we can have functions that
feed data to things that will be indexed (computed column or indexed view).
User-defined functions can be either deterministic or non-deterministic. The determinism is not defined
by any kind of parameter, but rather by what the function is doing. If, given a specific set of valid inputs,
the function will return exactly the same value every time, then the function is said to be deterministic.
An example of a built-in function that is deterministic is SUM(). The sum of 3, 5, and 10 is always going
to be 18 — every time the function is called with those values as inputs. The value of GETDATE(), however,
is non-deterministic — it changes pretty much every time you call it.
To be considered deterministic, a function has to meet four criteria:
❑ The function must be schema-bound. This means that any objects that the function depends on
will have a dependency recorded and no changes to those objects will be allowed without first
dropping the dependent function.
❑ All other functions referred to in your function, regardless of whether they are user- or systemdefined,
must also be deterministic.
❑ The function cannot reference tables that are defined outside the function itself. (Use of table variables
is fine. Temporary tables are fine as long they are defined inside the scope of the function.)
❑ The function cannot use an extended stored procedure.
The importance of determinism shows up if you want to build an index on a view or computed column.
Indexes on views or computed columns are only allowed if the result of the view or computed column can
be reliably determined. This means that, if the view or computed column refers to a non-deterministic
function, no index will be allowed on that view or column. This situation isn’t necessarily the end of the
world, but you will want to think about whether a function is deterministic or not before creating
indexes against views or columns that use that function.
So, this should beget the question: “How do I figure out whether my function is deterministic or not?”
Well, beyond checking the rules we’ve already described, you can also have SQL Server tell you whether
your function is deterministic or not — it’s stored in the IsDeterministic property of the object. To
check this out, you can make use of the OBJECTPROPERTY function. For example, we could check out the
determinism of our DayOnly function that we used earlier in the chapter:
USE Accounting;
SELECT OBJECTPROPERTY(OBJECT_ID(‘DayOnly’), ‘IsDeterministic’);
It may come as a surprise to you (or maybe not) that the response is that this function is not deterministic:
-----------
0
(1 row(s) affected)
Chapter 13: User-Defined Functions
423