Fortran and Transact SQL

Очень смешно перекладывать fortran to transact SQL. Как ни странно, но очень сходный подход. Я бы даже сказал не отличимый.

declare @m int,@i int, @j int
select @m =5
declare @co1 float, @a float,@a1 float, @a2 float, @e float, @e0 float, @ip int, @u float, @i1 int, @i2 int
declare @rk float, @rk2 float, @is int, @sv float, @err float, @ret int
declare @tl1 float, @tl2 float
select @tl1=0.00585649
select @tl2=0.1
select @ret=0
select @co1=1.0
select @a = -((select r from #rx(nolock) where i=2) / 
  (select r from #rx(nolock) where i=1) )
update a set a = @a where i=1 --A(1)=-RX(2)/RX(1)
update a set rc = @a where i=1 --RC(1)=A(1)
select @e=((1-@a*@a)*(select r from #rx where i=1) ) --E=(CO1-A(1)*A(1))*RX(1)
select @e0 = (select r from #rx where i=1) --E0=RX(1)
select @ip=@m-1 --IP=M-1
select @i=2
while (@i<=@ip) --DO 1 I=2,IP
begin 
  select @u=(select r from #rx(nolock) where i=@i+1) --U=-RX(I+1)
  select @u=-@u 
  select @i1=@i-1 --I1=I-1 
  select @j=1 
  while (@j<=@i1) --DO 2 J=1,I1 
  begin 
    select @a=(select a from a(nolock) where i=@j)
    select @a1=(select r from #rx(nolock) where i=@i-@j+1) select
    @u=@u-@a*@a1 select @j=@j+1 --U=U-A(J)*RX(I-J+1) 
  end --2 CONTINUE
  select @rk=@u/@e --RK=U/E 
  select @rk2=@rk*@rk --RK2=RK*RK 
  if(@rk2>1)
  begin 
    select @ret=1 --IF(RK2.GT.1.) STAT=1. 
    select @is=@i --IF(RK2.GT.1.) IS=I 
    goto fin -- GOTO 4
  end
end
fin:

Forums: 

Да, TSQL дрстаточно примитивен

Да, TSQL дрстаточно примитивен
В yukon собираются ввести TRY..CATCH
Но классов там не будет по очень грубоким причинам
А вот почему там нет нормальных циклов ума не приложу

Какие циклы в твоем понимании

Какие циклы в твоем понимании нормальные?
Циклы в Transact-SQL нужны только из-за курсоров.
А курсоры нужны, потому что большинство программистов привыкли к процедурным языкам, поэтому на SQL пишут так же, как на С или FORTRAN.
Если бы было строгое доказтельство полноты SQL, то курсоры можно было бы послать куда подальше ...

По моему опыту, очень мало программистов, умеющих писать на SQL.

Изображение пользователя ipanshin.

очень мало програм

очень мало программистов

Я бы так сократил. А программистов с SQL построением мозгов - просто видимо нет. А, если еще добавить к этому с наклонностями сисадмина.
Если решу задачу реализации рекуррентного алгоритма без циклов на sql то напишу.

А за чем это надо?Есть языки

А за чем это надо?
Есть языки где такие алгоритмы реализуются без проблем, то же FORTRAN.
Лучше решить задачу подключения процедуры на FORTRAN'е в виде xp в SQL.

По поводу программистов согласен.
Программист, в настоящие время, состит из 3-х разных людей: аналитик, кодер, тестер. Ну прям святая троица :)

Изображение пользователя ipanshin.

Да, согласен. Проще видимо нап

Да, согласен. Проще видимо написать и подключить sp.dll.
Больше трех для человеков до сих пор много.

Изображение пользователя ipanshin.

Лучше решить задач

Лучше решить задачу подключения процедуры на FORTRAN'е в виде xp в SQL.

Я подумал и не согласился. Это как раз задача БД предсказывать, а dll через xp - это операционное действие вне БД.
Задача предсказания или экстраполяции возникает именно над данными в БД. Например, предсказать ход торгов или вероятность того, что Пупкина выберут президентом или тот и тот будут фаворитами гонки. Все эти задачи для БД нет смысла вычислять на стороне. Это ее прерогатива и SQL должен это делать.

Предсказания, построение тренд

Предсказания, построение трендов и т.п. - это задачи анализа. СУБД решает задачи связанные с получением данных, а не их интерпритацией (=порождение доп. знания). Т.е. это задача как минимум OLAP.
Не вижу ни чего плохого в том, что бы выбранные данные передаются для анализа внешнему средству. В конце концов, все общение с БД строиться через клиентов, по сути тоже внешние приложения.

Все упирается в оценку затрат, что выгоднее писать алгоритм на SQL или подключить внешнюю библиотеку.

Изображение пользователя ipanshin.

Сережа, ты и прав - и не прав.

Сережа, ты и прав - и не прав. Конечно, это задача анализа. Но цель анализа вовсе не та, чтобы дать пищу аналитику, чтобы он морщил лоб, а запустить задачу синтеза in real time. Ну аналогично задаче предсказания речи, когда из белого шума получаешь голос с заданным спектром.

выбранные данные передаются для анализа внешнему средству

Это будет потом. А я пока рассчитываю коэффициенты модели предсказания, которые вообще никуда не должны уходить.

Или я что-то недопонимаю в общении dll-sp. Расскажи более подробнее свою схему.

Предупреждение: я не предлагаю

Предупреждение: я не предлагаю конкретную схему, т.к. не знаком в деталях с твоей задачей.

Я исхожу из философии предназначения того или иного инструмента. СУБД предназначена для хранения и доступа к информации. Агрегатные функции - это предел обработки выбранныз данных для СУБД, дальше в ход должны пускаться инструменты предназначенные для анализа. Мой подход состоит в том, что у любого инструмента есть естественные ограничения, которые можно обойти только с потерей эфективности. Для каждой задачи надо выбирать наиболее подходящий инструмент.

Изображение пользователя ipanshin.

только с потерей э

только с потерей эфективности

Кто нибудь считал потери? Например
while() in sql and for() in c
update a set a where i=@i in sql and a(i)= in c

для хранения и доступа к информации.

Это IMHO при отсутствии sp.