Наступал я уже на эти грабли... Оформить в виде функции - это естественное желание. Только в функции нельзя использовать динамический SQL.
Я выкрутился так. Содержимое вообще всех справочников у меня лежит всего в паре таблиц. В первую таблицу помещаются системные поля всех справочников плюс Lookup-поле (мы его еще называем "главным полем"). Системные поля - это идентификаторы справочника и записи, дополнительные системные поля для работы с древовидными справочниками, дата и время создания записи, информация о том, с какого компьютера и кем запись была создана. Главное поле (Lookup-поле) - это то поле, значение которого "светится" как выбранное в записи, ссылающейся на запись данного справочника. Lookup-поле обязано быть совместимым с varchar(). Все остальные поля (мы их называем additional-полями) помещаются во вторую таблицу и имеют тип sql_variaint. Значения разных полей одной записи справочника хранятся в разных записях таблицы №2. Для формирования собственно справочника со множеством полей используются View с instead-триггерами (View содержит столько Left join с таблицей №2, сколько additional-полей в справочнике). Текст VIEW и всех instead-триггеров строится автоматически с помощью специальной хранимой процедуры-скриптовалки по содержимому таблиц метаданных, в которых описана структура справочников. Модификация структуры справочника сводится к перескриптованию VIEW и instead-триггеров (удаление их и повторное создание). При этом все данные в справочнике остаются в целости и сохранности. Более того, есть возможность восстановить удаленное поле справочника вместе со всем его содержимым даже после его "удаления" из структуры справочника. Отсутствуют проблемы со множествами вариантов всяких ALTER TABLE..., которые во всех комбинациях пришлось бы перебирать в зависимости от разных вариантов модификации струтктуры. К тому же, на выполнение ALTER TABLE существует море всяких ограничений и требований в последовательности выполнения определенных операций. В частности, могут возникнуть серьезные проблемы с динамическим скриптованием, если таблица содержит в каком-либо поле в качестве default-значения вызов UDF, которая обращается к этой же самой таблице. При создании таблицы - настоящий танец с бубном. Сначала нужно создать таблицу без дефаулт-значения, потом создать функцию, и наконец с помощью Alter table подсунуть UDF в качестве default в таблицу.
Более того, в качестве решения проблемы с Default-значениями, я использовал специфический подход. Default-зачения хранятся в таблицах метаданных, и обращение к ним производится с клиента в момент попытки добавить новую запись. В результате юзер видит дефаулт-значение в форме у себя на экране именно в том виде, как оно будет добавлено в таблицу еще до того, как произойдет собственно добавление записи , а не после него.
Ну, на самом деле все сказанное - это очень упрощенный взгляд на проблему. На самом деле таблиц не две, а больше. Еще в паре таблиц я храню историю модификации записей справочников. Среди справочников есть ряд "системных" справочников, которые "вписаны" в обощенные алгоритмы работы всех остальных справочников. Таковым, например, является справочник свойств. Свойства - это динамически прицепливаемые к записям атрибуты, которые в древовидных справочниках с использованием иерархии справочника и механизма наследования свойств по этой иерархии позволяют творить настоящие чудеса. В частности, юзеры сами могут расписать структуру атрибутов для записей в разных ветвях одного и того же древовидного справочника. В результате в разных частях одного и того же справочника записи имеют разные атрибуты (вроде как разный состав полей). По свойствам работают фильтры, сортировка, поиск точно так же как и по полям. Только перечень полей жестко фиксирован, а состав свойств и их значение может быть модифицировано для любой записи справочника прямо во время текущей работы пользователя, без перехода в какие-либо режимы "конструктора".
В своих проектах мы стараемся чаще использовать свойства и реже поля. Дело еще в том, что поля (особенно, если много и полей, и записей) достаточно долго закачиваются с сервера, что приводит к притормаживаниям вывода справочника (поля выводятся в гриде). А свойства выводятся в отдельном фрэйме окна справочника только для одной - текущей записи. В результате использование справочника со свойствами наиболее отвечает концепции тонкого клиента - загрузка информации с сервера на клиент производится мелкими порциями и только той информации, которая в данный момент требуется.

>Ваш ответ похож на анекдот о новом русском у которого засорилась пепельница в автомобиле и он решил купить новый автомобиль

Не спорю, похож. О концепции используемых мной макрообъектов я уже несколько раз высказывался. И так же несколько раз предупреждал о том, что трудоемкость реализации этой концепции сравнима с выкапыванием чайной ложкой тунеля сквозь гору. Но когда все уже сделано... Это так классно! Справочники у нас уже сделаны, в настоящий момент идет работа над другими макрообъектами. Но когда я создаю новый справочник (или проекцию на существующий справочник - это последнее слово в нашей концепции справочников), либо модифицирую структуру существующего справочника, я просто пищу от удовольствия.

>Особенно интересно разобраться с таблицей (таблицами) метаданных, с описанием структуры справочников, позволяющей автоматически генерить VIEW и триггера, а так же ХП которая делает это

Текст ХП занимает около 2000 строк. При создании справочника она генерит 4 VIEW и 9 Instaed-триггеров, размер которых зависит от типов полей справочника (кроме скалярных типов есть, например, тип "множество" и тип "ссылка на справочник") и их количества, а также от того, является справочник линейным или древовидным и задействован ли в нем механизм свойств.
Размер простого триггера (не instead), прицепленного к главной таблице составляет около 1500 строк. И т.д. и т.п. Мы убили груду времени, чтобы все это накропать. Однако, чтобы все это прочитать и с нуля разобраться, IMHO, времени нужно еще больше . Замечу на всякий случай, что гигантские тексты триггеров и хранимых процедур не считаю достоинством концепции. Наоборот, в плане быстродействия подобные монстры требуют установки на сервере штабелей оперативной памяти, чтобы быстродействие устраивало пользователей. Гибкость бесплатно не дается. С другой стороны, нам удалось избежать использования динамического SQL, что позволило интегрировать собственные средства безопасности в среду безопасности SQL-сервера.