Меня удивляют эти поцреоты

[@JustLuckyGuy]

>Полученные данные показали, что время выполнения MySQL реализации функции ‘fibonacci’ в 16.5 раз превышает время выполнение аналогичной функции на PHP.

[@atd]

Оргвыводы: использовать процедурное расширение СУБД нужно (мое мнение) для администрировании баз данных, но никак не для реализации бизнес-логики, что часто можно слышать от отдельных товарищей. К.О.

Неправильные оргвыводы. Точнее, не универсальные.

Правильный вывод: не считайте числа фибоначи на стороне БД.

Если логика не считает чисел фибоначи или интегралы, а содержит очень много выборок из БД и вставок туда же, то быстрее будет работать хранимка, а не перегон больших объёмов данных в php и обратно. Ваш К.О.

[@BugEater]

Перегон больших объемов данных это уже их оперы администрирования баз данных. У тебя запись экземпляра элемента модели данных это 10 000 строк в N таблицах, который извлекается одним запросом, либо одна строка в тех же N таблицах?

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

Ваш К.О.

[@atd]

Обычно, бизнес-логика — это не только выборка.
А при администрировании БД даже страшно представить, зачем надо перекачивать много данных. Это же работа на уровне DDL / настроек сервера. А много данных качаются бэкапом или репликацией, тут уже прерогатива движка сервера БД, и хранимки/PHP тут совершенно непричём.

[@remal]

Этот вывод абсолютно не следует из бессмысленного бенчмарка.

А вот почему не следует пихать логику в БД очень хорошо описано тут: habrahabr.ru/blogs/refactoring/65432/

[@XuMiX]

[trollmode]
а вот в номальной СУБД можно было бы написать хранимку на java/c/c#/…
[/trollmode]
:)

[@AxisPod]

Хранимки в БД необходимы только для работы с хранимыми в БД данными, но ни с чем другим, если нужен высокая производительность используйте соответствующие языки программирования, можно написать на c/c++ библиотеку для PHP, довольно просто делается.

[@Fiery_Fenix]

Просто для констатации факта…

2000 запусков
PHP: 0.45 секунд
PostgreSQL pl/pgsql: 0.018 секунд

1 запуск
PHP: 0.2 миллисекунды
PostgreSQL pl/pgsql: 0.027 миллисекунды

PS Да, рекурсия в PostgreSQL поддерживается и опять да — функция IMMUTABLE.

[@FloppyFormator]

return fibonacci(n -1) + fibonacci(n -2)

Хрестоматийный пример неправильного подхода к рекурсии.

И, да: почему всего 11? Слишком мало, развернуться негде.

[@BugEater]

Если брать больше число, то нужно изменять значение параметра @@thread_stack. Я решил не дергать mysql сервер и остановился на этом числе.

В чем же заключается неправильный подход, позвольте поинтересоваться?

[@FloppyFormator]

Число вызовов функции растёт показательно (2 ^ n) по мере роста глубины рекурсии.

Небольшой пример на Perl:
$ time perl -e 'sub fib1 {my $n = shift; return 1 if $n == 1 || $n == 2; return fib1($n - 2) + fib1($n - 1)} my $r; $r = fib1(11) for 1..2000; print "$r\n"'
89
real 0m0.575s
...

$ time perl -e 'sub fib2{my $n = shift; return 1 if $n == 1 || $n == 2; my ($a, $b) = (1, 1); for my $i (3..$n) {($a, $b) = ($b, $a+$b)} return $b} my $r; $r = fib2(11) for 1..2000; print "$r\n";'
89
real 0m0.039s
...

То есть, вы в корне неправильно поступаете, измеряя производительность двумя разными алгоритмами.

[@FloppyFormator]

А, вы и в MySQL через рекурсию реализовали. Не разглядел, тогда алгоритмы не такие уж и разные.