DeffКакие у меня есть идеи.
Начать размышлять удобнее со второго варианта. Проблема этого подхода в том, что в "сразусозданнуюфункцию" будет передаваться вагон неверифицируемых данных. То есть, Вы будете передавать туда какую-то дату, какой-то тип и т. п., но нет совершенно никаких гарантий, что именно нужные, и Вы это никак не проверите (пока они не станут нужны по бизнес-логике). Скажем, в одном случае у Вас доступны две даты: какую из них передадите? Или обе? А в другом случае ни одной. Заджойните таблицу с датой? Какую именно? Передадите null? Вообще не передадите? В общем, это будет просто свалка с тремя решаемыми задачами: осложнить и запутать начальное написание кода, осложнить и запутать отладку при изменении бизнес-логики, создать псевдоощущение "раз, поменяли - и всё работает по-новому".

Первый подход не приносит ничего нового, просто вместо "бегать и менять код" будет "бегать и менять метаданные". Поскольку проблемы будут ровно те же, что и в первом случае: надо взять откуда-то данные, причём не абы какие, а именно нужные, а какие нужные - вопрос к человеку.

Третий подход смущает.. зачем знать? Ну даже с учётом неумения MSSQL отслеживать зависимости, их обычно несложно найти (если не брать в расчёт некоторых сильно нетривиальных методов кодирования отдельных программистов).

А в целом... Вы исходите из того, что есть некий более-менее устойчивый контекст, в котором считается и может быть посчитана цена, причём при изменении бизнес-логики меняется способ расчёта, но контекст остаётся неизменным. Если так, никто не мешает обернуть этот контекст во view и сделать цену вычисляемым полем. Вот только предпосылка о неизменности имхо сомнительна.