Хранимые процедуры. Кто быстрее

Чую скоро, для оценки производительности хранимок, начнут на них 3D сцены обсчитывать. и писать чтото типа — мускуль сосет, ни транзакций ни поддержки CUDA :)

вы забыли postgresql)

[минутка КО на Хабре]
СУБД — система управления базами данных.
Главная ее задача — обеспечивать целостность данных и скорость доступа к ней. Ну, плюс безопасность, масштабируемость и т.д. — то есть все то, что относится к хранению данных. Плюс некоторое обеспечение корректности за счет внутренних проверок и условий (сравнение полей и віборок с минимальными вычислениями).
Бизнес-логику надо выносить наружу.
По большому счету самым оптимальным является трехзвенная система — СУБД + app server + клиент. Клиент — отображение и взаимодействие, сервер приложений отвечает за бизнес-логику, СУБД хранение и доступ к данным. Относительная независимость каждого компонента обеспечивает стабильность.
Писать High Perfomance Computing на интерпретируемых языках и хранимых процедурах — это жесть. :)

а выносить логику за пределы СУБД

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

Запустил для интереса на работе на oracle 7.36 сек
машина у меня хлам
Celeron 2.67

896 ОЗУ

есть мнение, что для таких вот задач и встроили собственные CLR внутрь SQL Server и JVM в Oracle.

Спасибо, повеселили :)
Анонимный блок для Оракл (проверял, выполняется приблизительно одинаково с хранимой процедурой):

declare
  U number:=1;
  S number:=1;
  I pls_integer:=3;
begin
  WHILE (abs(U) >= 0.0000001) loop
    U:= -U*1*1*(I-2)/I;
    S:= S + U;
    I:= I + 2;
  END loop;
  dbms_output.put_line(4*S);
end;

Время выполнения около 4.5 сек.
Конечно, нужно на одинаковых машинах скорость замерять.