Лет 7 назад были великолепные перлы!

Что логика в виде for'ов значительно более понятна человеку, чем select. Потому select отстой, а всю логику нужно делать на java for'ами

Специально на принтере распечатал и на стенку на работе повесил. Цитата не точная. Точную цитату из подфорума Java искать лениво

Не истины ради, а глубоко для оффтопа и флудерства

Addx2. Скорость передачи информации внутри Сервера БД (внезапно!) выше, чем передача информации с/из СП в БД. Так что прочитать - исправить - записать из ХП будет существенно быстрее, чем прочитать в БД - обработать в СП - записать в БД.

Не все так однозначно ( C ) дочь офицера

Т.к. встроенные языке БД обычно более "убогие", чем некоторые универсальные языки (java) + имеют ограниченный набор возможностей по работе со сложными типами данных и коллекциями, очень легко придумать задачу, когда проще вынуть данные из СУБД, обработать на "нормальном" языке и положить обратно.

Например: расчеты на графах, обработка ГЕО-данных, парсинг / формирование RTF, компрессия / декомпрессия JPEG, сжатие фильмов и так далее. Даже если СУБД это и умеет. Это задача не для СУБД и ее вполне осмысленно вынести за ее пределы.

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


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

Тот же 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 фигурировали в более общем виде "сжатие фильмов". Вы просто не внимательно читали.