Поскольку оффтоп, убрал под спойлер.


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

Тот же Oracle PL/SQL, много он предлагает типов данных и коллекций ? Массивы и....

Решать __сложные__ алгоритмические задачи на PL/SQL - вот именно, что получается "перебором" и на уровне поделок на Basic'е в средней школе.

YuRockпредусмотрены плагины для того, чтобы можно было сделать с данными все, что хочешь

Иногда не все, что можно сделать - нужно делать )))

Ну и реализация "плагинов", по крайне мере у Oracle, оставляет желать лучшего. При вызове ф-ции из плагина (например spatial) время переключения контекста SQL - Java внутри СУБД, может зашкаливать за всякие границы добра и зла. Часы, сутки на достаточно небольших объемах данных (конкретно - банальное преобразование из WGS-84 в Spherical Mercator). Получение же данных при array / bulk fetch и таком же insert/update - единицы секунд, обработка в __специализированной__ библиотеке десяток секунд, единицы минут.

Можно тут же и XML вспомнить. У Oracle не все настолько плохо, но то же, грамотный код на приспособленном для этого языке / библиотеке может быть на порядок(и) быстрее, чем та же задача, реализованная чисто на СУБД. Разумеется, зависит от задач.

IMHO & AFAIK

Желательно сначала думать. Для каких задач какое средство предназначено и какие + и - из этого получаются.

Что с желанием "все сделать на сервере приложений", что с желанием "все сделать одним select'ом". Крайности и в том и в другом случае до добра не доводят.

IMHO & AFAIK

YuRockтолько все равно на сервере, прямо в процессе сервера, а не гоняя их туда-сюда

Вопрос цены. Процессор СУБД достаточно дорогое удовольствие. Не только в производительности/стоимости, но и например в надежности

Загружать его __несвойственными__ ему тяжелыми задачами - в реальных и крупных системах может быть крайне разорительно.

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

Ну и падение отдельного блейд-сервера с Out of memory относительно безобидно, а падение ядра СУБД корпоративной системы из-за такого изнасилования - вещь сильно не желательная.

Новичок ООП..удивлён отсутствием в списке MP3, JPEG, MKV, КПСС, ГИБДД ...)

Я ПРОТЕСТУЮ !

В моем списке явно было JPEG, а MP3 и MKV фигурировали в более общем виде "сжатие фильмов". Вы просто не внимательно читали.