UDF реализованы в версии MS SQL Server 2000. В более ранних их действительно нет.

Подобный, либо НЕ подобный подход требует принятия тщательно взвешенного решения. Рекомендую тщательно подумать, прежде чем использовать что-либо функцие-подобное. Я юзаю SQL-2000, но стараюсь избегать использования UDF, которые возвращают скалярные значения, используемые внутри запросов, например, во фразе WHERE. Конечно, подобный подход существенно упрощает написание кода, поскольку позволяет его разбить на структурно автономные "черные ящики". Однако, тормоза при вызове функций возникают тоже приличные. Следует учесть, что функция вызывается для каждой записи набора данных. При этом происходит сохранение точки возврата в стекоподобной структуре, передача параметров, выполнение полностью обособленного скрипта, план выполнения которого не может оптимизироваться, объединившись с планом выполнения базового запроса. В результате в подобных запросах происходит, как правило, очень много совершенно излишних шевелений данными плюс операции над стеком, что приводит к существенному притормаживанию.
Очень часто действия, выполняемые в функции, можно объединить с действиями, выполняемыми в базовом запросе, в один скрипт. Когда это действительно возможно, я всегда так и делаю. Да это приводит к громоздким и малопонятным текстам запросов с подзапросами, однако у такого запроса единый монолитный план выполнения, который может быть оптимизирован и чаще всего он действительно лучше оптимизируется, нежели более понятные два скрипта, вызывающие один другой.
Я пришел к выводу, что из всего механизма UDF наиболее полезными на практике являются inline-функции, возвращающие table. Не зря MS отделила inline-функции от всех прочих, в том числе и синтаксически. Их план выполнения может сливаться с планом выполнения базового запроса и проходить совокупную оптимизацию.
Приведу два примера.
1. НЕ inline-функция.
create function Fn()
returns @T table (Fld int)
as
begin
insert into @T
select SomeField from SomeTable
end

2. Inline-функция.
create function Fn()
returns table
as
return select SomeField as Fld from SomeTable

Обе функции, по-сути, выполняют одно и то же. Теперь допустим, что SomeTable содержит 1000000 записей и по полю SomeField построен индекс.
Запускаем запрос:
select * from dbo.Fn() where Fld=5

Если при этом вызывается функция варианта 1, ее выполнение может потребовать нескольких минут. Если вызывается функция варианта 2, она выполнится за доли секунды. Почему такая разница?
Потому что условие фильтрации, заданное в конечном запросе, способно подняться по плану выполнения запроса, проникнуть в план выполнения inline-функции и заставить фильтровать записи на ранней стадии - в теле самой функции. Функция же варианта 2 в любом случае будет сначала выполнять полное сканирование таблицы, выборку всех записей, передачу этих записей в план запроса, из которого вызвана функция, и только после этого фильтрацию записей с повторным сканирование всего набора данных. Согласитесь, разница существенная.