Таааак - видно, что народ MSSQL 2000 не юзал. Если сравнить такие функции с view, то согласитесь что не всегда с помощью view можно впихнуть select, особенно когда он четко ориентирован на определенные параметры. Я не имею ввиду примитив типа "select * from Table where Field = @Value", речь идет о запросах с подзапросами, частенько содержащими агрегатные операции, в которых не возможно вернуть все множество вариантов, т.е. идет обработка по четко заданным параметрам. В качестве примера могу подкинуть такое:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
select i.CalcAlgorithmImplement_id, o.TypeCalcObject_id, a.CalcObject_id, i.CalcAlgorithm_id, c.CalcDate
from CalcAlgorithmImplement i
inner join CalcAlgorithm a on i.CalcAlgorithm_id = a.CalcAlgorithm_id
inner join CalcObject o on a.CalcObject_id = o.CalcObject_id
inner join
(select ci.CalcAlgorithm_id, ci.CalcDate, Max(ci.SaveDate) as MaxSaveDate
from CalcAlgorithmImplement ci
inner join
(select CalcAlgorithm_id, Max(CalcDate) as MaxCalcDate
from CalcAlgorithmImplement
where CalcDate <= @CalcAlgorithm_CalcDate and
SaveDate <= @CalcAlgorithm_SaveDate
group by CalcAlgorithm_id) as s on ci.CalcAlgorithm_id = s.CalcAlgorithm_id and
ci.CalcDate = s.MaxCalcDate
where ci.SaveDate <= @CalcAlgorithm_SaveDate
group by ci.CalcAlgorithm_id, ci.CalcDate) as c on i.CalcAlgorithm_id = c.CalcAlgorithm_id and
i.CalcDate = c.CalcDate and
i.SaveDate = c.MaxSaveDate
Как видно из этого запроса, с таблицы, в которой хранится история данных с помощью двух дат - CalcDate (расчетный месяц) и SaveDate (месяц актуальности информации, т.е. ввода в действие), view на такой запрос не напишешь. С другой стороны каждый раз совать его в запросы ХП, тригера и клиента печально - получение текущей информации на указанный период времени с помощью этого запроса используется очень во многих местах проекта и согласитесь если что, легче его поменять в одном месте.
По поводу вопроса насчет условий - все просто. У MSSQL 2000 есть 2 типа функций, возвращающих набор данных. Inline смахивает на параметризированный вьювер и кроме наличия параметров ничем от него больше не отличается. Еще есть table-функции. Т.е. в такой функции указывается, что будет возвращена таблица, ей указывается внутреннее для функции имя и описывается ее структура. В тексте функции вы можете писать любой код и вгонять любые данные через insert в эту таблицу. Далее она используется в FROM запросов наравне с таблицами и вьюверами.
На этом можно наверное тему прикрывать и завязывать с просветительской работой. Я нашел аналог inline-udf функций, немного правда не оттуда, откуда ожидал, но вариант рабочий - благодаря тому, что Sybase поддерживает область видимости переменных, то в принципе никто не запрещает в вьюверах использовать переменные, типа того:
1.
2.
3.
4.
5.
create view TestParameterView
as
select *
from Table1
where Field1 = @Value
Прекрасно компилится, потом можно использовать так:
1.
2.
3.
4.
5.
declare @Value int
set @Value = 1
select *
from v_TestParameterView
Получается почти что тоже самое, что мне и требовалось. В кач-ве недостатков такого метода по сравнению с inline udf функций можно отнести написание лишнего кода по обьявлению переменных, которые будут потом использоваться во вьювере, отсуствие контроля отсутствия переменных при компиляции и необходимостью делать для каждого вьювера уникальные имена используемых им переменных, чтобы не было случайных пересечений.
Всем большое сенкс за внимание к этой теме :)
