# Calculating Age with an Inline Table Valued Function

I was working on a data warehousing project recently where I was working with VERY large data sets. It was a customer insight warehouse and as part of that warehouse details about customers were stored including their DOB.

Part of the requirement was to keep a record of their age at the time of the transaction and also be able to track that person’s current age.

As with most things we always try to re-use something (a piece of code, a process) that we’ve used before to save time right?

So there was a UDF in the database called ufn_GetAge. This was a fairly typical scalar UDF that took two date parameters and then worked out the elapsed time between the two to calculate an age:

```
CREATE FUNCTION [dbo].[ufn_GetAge]
(
@DOB    DATETIME,

@Date       DATETIME
)

RETURNS INT

AS

BEGIN

DECLARE @Age         INT

IF @DOB >= @Date

RETURN 0

SET @Age = DATEDIFF(YY, @DOB, @Date)

IF MONTH(@DOB) > MONTH(@Date) OR

(MONTH(@DOB) = MONTH(@Date) AND

DAY(@DOB)   > DAY(@Date))

SET @Age = @Age - 1

RETURN @Age

END

```

This had always “worked fine” before and so it was re-used as part of an ETL load for a VERY large data set (300+ million rows). So what happened when we ran the ETL? Well, all I can tell you is it took a very long time…

Some debugging on the ETL was performed and this function was found to be the culprit. A new solution was called for, enter the Inline Table Valued Function.

So… we needed an accurate way of calculating the difference between two dates in order to come up with an Age (in whole years). I wrote several functions that should have done the trick but under testing showed the results generated were not always quite correct. Eventually I came up with a piece of code that does the trick:

```
CREATE FUNCTION [dbo].[iTVF_CalculateAge]

(

@DOB date,

@Date date

)

RETURNS TABLE

AS

RETURN

(

SELECT

CASE

WHEN (@DOB IS NULL) OR (@Date IS NULL) THEN -1

ELSE DATEDIFF(hour,@DOB, @Date)/8766

END AS Age

)

```

CAVEAT: This always seems to come up with the correct answer and passed all the unit tests we ran on it. If you wish to use it, ensure that you test it to make sure it generates the results you need. If you do find an inaccuracy then do please let me know in the comments below this post.

So… how does this new inline function perform when compared to the original UDF above? I’m glad you asked!

Firstly I created a Test database and two test tables. Once called Test and once called Test2. Both contain two columns, an ID (INT IDENTITY (1,1)) and a DOB (DATE). I inserted 1 million dates into Test and 10 million dates into Test2.

Testing, Testing, 123….

Firstly the 1 million row dataset:

```
SET STATISTICS IO ON;

SET STATISTICS TIME ON;

SELECT t.ID, t.DOB FROM dbo.Test t;

SELECT t.ID, t.DOB, [dbo].[ufn_GetAge](t.DOB,GETDATE()) FROM dbo.Test t;

SELECT t.ID, t.DOB, age.Age

FROM dbo.Test t

CROSS APPLY [dbo].[iTVF_CalculateAge](t.DOB,GETDATE()) age;

SET STATISTICS IO OFF;

SET STATISTICS TIME OFF;

```

The first query is run merely to get an idea of raw performance to select out the data (no functions or calculations applied), the second query runs the UDF and the third uses the new inline function.

And so onto the results:

```(1000000 row(s) affected)
SQL Server Execution Times:
CPU time = 328 ms,  elapsed time = 5164 ms.
(1000000 row(s) affected)
SQL Server Execution Times:
CPU time = 5397 ms,  elapsed time = 6567 ms.
(1000000 row(s) affected)
SQL Server Execution Times:
CPU time = 874 ms,  elapsed time = 5409 ms.```

As you can see from the results, the raw select of all the data (1 million rows) it took 5164ms, the UDF took 6567ms and the iTVF took 5409ms. So on time alone the iTVF wins, but the real benefit is in the CPU cycles… the iTVF took only 874ms where the UDF took 5397ms! I declare iTVF the winner.

And over 10 million rows:

```(10000000 row(s) affected)
SQL Server Execution Times:
CPU time = 3152 ms,  elapsed time = 49175 ms.
(10000000 row(s) affected)