iscrafm Алексей КЭто вы считаете труднореализуемым в SQL? Вроде можно всё без курсоров в одном select сделать.
предлагаю учредить сообщество разработчиков 3D игр на SQL.

И чтобы без курсоров! Ибо с курсорами- неспортивно!

Алексей К2 iscrafm

Тут главное чтобы без фанатизма :-))

По теории распределённые приложения создаются для повышения производительности системы, но ИМХО, чаще принимая решение разместить вычисления в СУБД, AS или ещё где то разработчики руководствуются совсем другими соображениями. Обычно это доводы: так быстрее и проще сделать. В частности плохой метод, который бомбит СУБД SQL запросам будет лучше работать в СУБД, чем удалённо, но ведь от этого он не станет хорошим методом.

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

Алексей Кmcureenab, ты бы хоть книжку какую прочитал бы, перед тем как тут выступать. Рекомендую начать с этого .

В статье речь идёт о клиенте-front end приложении, которое решает задачи презентации данных пользователю системы. Естественно по сравнению с таким клиентом СУБД выполняет самую большую часть работы - находит, фильтрует, агрегирует даные. Дальнейшим развитием этой ахитектуры является многозвенная архитектура. В задаче расчёта ЗП, и пакетных вычислений вообще (своего рода back office) взаимодействие с пользователем не требуется. Так что ссылка нерелевантна теме.

Пакетная обработка данных как правило использует значительную чать сведений, хранящихся в БД. Ну и отлично! Будем считать в СУБД. Но, запросы к БД выполняются не так быстро как хотелось бы, да и реляционное представление не удобно. Ok. Решаем эту проблему. Кэшируем данные, заодно преобразуем их в структуры, более подходящие для расчётов. Ключи разрешим в указатели, организуем объекты в коллекции с быстрым и удобным доступом, и т.д.. И вот мы уже видим, что после начальной загрузки кэша БД нам уже не нужна. А тут ещё пользователи со своими запросами и ХП то и дело отнимают ресурсы CPU. Так ну её в баню, эту СУБД. Перемещаем процесс обработки на отдельный узел, благо, скорость ЛВС уже Gbit'ами измеряется. Ну в общем и всё. Мы получили распределённое масштабируемое решение.
Обращаю внимание, что это не многозвенное решение. Это больше похоже на back office. Т.е. внешний сервис лежит не между клиентом и СУБД, а находится за СУБД, с точки зрения пользователя. Такие решения я видел в системах, где СУБД не подедерживала не только ХП, но даже SQL. Такие решения используются в системах реального времени. И т.д.