Давненько тут не был.
А какая занимательная дискуссия развилась!

ДжекНепотрошительЯ начал рассказывать вам о том, что реализовывать сложную бизнес-логику на ХП менее эффективно, чем на языках высокого уровня
Perl, Python, Java, Ruby, R - достаточно высокоуровневые языки для этой задачи? На них можно писать ХП.
Пруф: http://www.postgresql.org/docs/9.2/static/external-pl.html
Именно эта информация меня и сподвигла к решению применять такую архитектуру.

МСУМасштабируемость никакая и безопасность ни в красную армию.
http://ru.wikipedia.org/wiki/Трёхуровневая_архитектура
Я бы не был столь категоричен. Да, некоторые сложности с масштабируемостью есть, но они решаемы. Вплоть до того, что можно физически разделить ХП и данные, например используя это: http://www.postgresql.org/docs/9.2/static/dblink.html
Но тут появляется невиданная для классических "трёхзвенок" гибкость. Мы можем делить нагрузку на сервера не только по линии данные-математика, но и группируя данные с математикой. Например, редко используемые данные вместе с процедурами их обработки - на один инстанс, а динамично изменяющиеся данные, опять же, вместе с нужными ХП - на другой. И таки да, конечно, можем организовать несколько воркеров на разных инстансах.

Далее. Насчёт безопасности на уровне СУБД всё на весьма качественном уровне. Используем GRANT и VIEW.
У большинства "трёхзвенок", где все запросы к БД выполняются от имени привелигированного (в СУБД) пользователя, дела с безопасностью хуже. Например, велик риск SQL Injections.

Александр ПузаковlogoutЕщё раз повторю, что запрос получился огромным, сложно воспринимаемым. Но он принципиально показал, что задачу решить можно. И запрос был на удивление быстрым, даже без специальной оптимизации.
Можно и игрушечной лопаткой яму выкопать, будь желание на то... Но такое "ухищрение" мало подходит для реальной жизни. Например, время от времени меняется законодательство, касающееся оплаты труда и иже с ней, плюс руководство организации может принимать и изменять локальные нормативные акты, касающиеся оплаты труда. Вот тут-то и вылезет боком ваш "огромный, сложно воспринимаемый, трудно поддающийся изменению" запрос.
Абсолютно согласен с оратором. Похоже, мне не удалось донести мысль, что в продакшн это решение никто не собирался запускать именно по указанной выше причине. Речь шла только о том, чтобы на тесте проверить пригодность SQL к решению задачи начисления ЗП. В реальной жизни запросы можно разложить на отдельные, более понятные, представления. Повторюсь, что в результате я также пришёл к выводу, что расчёт необходимо делать последовательным на процедурном языке с записью результатов этапов вычисений. В таком случае и запросы SQL каждого этапа будут на порядки проще для понимания. Но весь расчёт делать на процедурном языке - непозволительное рсточительство.

Благодарю всех за конструктивный диалог.

ДжекНепотрошительНа чем бы не писались ХП, они все равно имеют достаточно узкий интерфейс для взаимодействия, т.е. по сути мы возвращаемся в старое доброе процедурное программирование. Пока система простая, это может быть эффективным. Но как только система разрастается, сопровождать ее становится очень неудобно.
Старое доброе процедурное программирование совсем не так плохо, как вам кажется. В своей практике повидал достаточно мощные системы, целиком созданные, долгое время работающие и активно развивающиеся именно на процедурных языках. Кстати, видел и обратные примеры с ООП. Так что ваш аргумент скорее отношу к грамотности разработчиков. Хотя, в целом по больнице, соглашусь, что на ООП код получается обычно более понятным и расширяемым.

ДжекНепотрошительСложнее становится и отладка, вам нужно будет отлаживать две системы, и сервер приложений, и ХП, с помощью разных инструментов.
Отладка кода на SQL, конечно, несколько сложнее. Тут принцип другой, не пошаговый. Но, прошу пояснить, вашу мысль. Если я использую в качестве сервера приложений именно ХП, то о каких разных инструментах идёт речь?

ДжекНепотрошительА риск SQL Injections в такой архитектуре ничуть не выше, чем риск забыть в ХП наложить ограничение прав доступа на пользователей.
Не скажите. У меня иной опыт. Когда пишешь кучу запросов сервера приложений, каждый раз нужно проверять права доступа. Легко что-то упустить. В нормальных СУБД, на мой взгляд, всё значительно логичнее. Прав у пользователя изначально нет никаких. Выдаёшь права только на нужные объекты на самом нижнем уровне. ХП более высокого уровня уже будут учитывать эти ограничения. Не забудешь.

ДжекНепотрошительНет, конечно же можно сделать какой-то сложный интерфейс, например, обмен данными между ХП через XML-пакеты. Но тогда нужно включать здравый смысл и задавать себе вопрос: а зачем тогда вообще нужны ХП?
Конечно, обмен данными между ХП не должен быть таким сложным. На практике хватает стандартных параметров ХП. И с добавлением параметров проблем обычно не наблюдается. В PostgreSQL, например, реализован даже полиморфизм ХП.

МСУЗачем забивать прикладную задачу к конкретному типу СУБД, если можно абстрагироваться от неё?
Можно. Любое решение - вопрос призов и цен. Вот, как раз с вашей помощью и пытаюсь понять, насколько существенны призы и цены альтернативного решения.

МСУУже 100 раз обсуждали. Никто не запрещает стартануть транзакцию и не закрыв её, уйти курить. Да и шарить БД для всего предприятия всем пользователям - самая ужасная практика, которая может только быть.
Видно, все эти 100 раз я отутствовал. Будьте любезны, резюмируйте опасность незакрытых транзакций и расшаривания БД? Или ссылочки на эти обсуждения.


МСУКаким образом тут возможна сиквел инъекция? Ты, надеюсь, понимаешь, что идиотов нет, которые будут публиковать в SOA подобные методы:




:)
Конечно, понимаю. Опять же, увы, я не редко встречал подобные методы. Опять вопрос сводится к профессонализму разработчиков.