Bely mcureenabСейчас вугружается около сотни записей в секунду. В перспективе нужно увеличить производительность на порядок.Что-то это слабо тянет на AS.
Типичное миграционное приложение, которых можно настругать с десяток.
Ну задача у него своеобразная... только это не AS.

На AS не тянет, а как сервер выгрузки, вполне. Если в системе есть AS, то неплохо будет вносить изменения в БД через него, а не напрямую, чтобы изменения сразу в его кэше отображались.

tygraТак вообще непонятно, откуда выгружается и куда.

Из БД в файл определённого формата.

Задача совершенно нехитрая, есть GUI, хранимая процедура на PL/SQL и модуль на C++, который работает в режиме сервиса Windows. Зачем так много?
1. Затем что PL/SQL не умеет делать GUI и не умеет делать требуемые файлы.
2. Затем что GUI работает на ПК оператора, а модуль на C++ на отдельном сервере, чтобы оператор не остановил его.

Спрашивается, зачем тут хранимая процедура на PL/SQL, если модуль на C++ может всё сделать не хуже?

Bely mcureenabСпрашивается, зачем тут хранимая процедура на PL/SQL, если модуль на C++ может всё сделать не хуже?Дествительно, незачем.
Но с такими рассуждениями можно легко докатиться до выводов "Зачем нужна БД, если все можно хранить в текстовом файле"

Так если можно, то почему бы не хранить в текстовом файле?

Видимо, нужно взвесть стоимость разработки и сопровождения собственного менеджера данных и покупки промышленной СУБД. Учесть перспективы развития системы, требования к её открытости, производительности, устойчивости к сбоям и т.д. и т.п.

Что касается моей задачи, PL/SQL модуль просится быть переписаным на C++, но этот модуль уже есть, он протестирован и работает, бюджет на переписывание начальство не даёт, вот и пользуемся тем что имеем.

tygra авторСпрашивается, зачем тут хранимая процедура на PL/SQL, если модуль на C++ может всё сделать не хуже?
Отвечается - зачем какой-то с++, если есть pl/sql, на котором можно сделать чего надо. И уж в крайних случаях - если например данные бд превращать в формат pdf, можно делать не с помощью pl\sql, а с помощью того, чего это умеет делать.

Прикол в том, что "это самое" (программа на C++), может сделать то что нужно, в том числе и то, что написано на PL/SQL. Так зачем PL/SQL и необходимость развёртывания ХП в СУБД? Короче, не выдумывай сырые частные решения не зная общей задачи.

tygraНо только приведенный пример никак не относится ни к распределенным вычислениям, тем более вообще никак к многозвенкам. Я тыщу раз говорил - слишком сильная трава у заядлых многозвенщиков, вы даже в обычном роботе, который чего-то там считает по расписанию, уже видите звено, и мало того, пытаетесь это воплотить в апп-сервере.

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

ИМХО, серверы приложений в настоящее время являются отличной масштабируемой платформой для развёртывания задач любой сложности. Специфические требования приложений реального времени или желание сэкономить на оборудовании заставляют разрабытывать внешние модули.

Alex_Toms
Пробовал я такой вариант, правда не в зарплате.
Приложение было на C++ Builder, считывал данные с сервака, обрабатывал из на клиенте, а потом обновлял на серваке. Сделал всё это в хранимой процедуре, скорость работы значительно возросла, и система стала просто летать по сравнению с первым вариантом.

Распределённые вычисления принципиально отличаются от локальных. Возможно, в данном случае система не учитывала сетевые задержки. Если программа на C++ изначально была основана на принципах локальных вычислений, то неудивительно, что её перенос на сервер позволил увеличить скорость вычислений.

Алексей К AlexTheRavenНесколько непонятно:
- в Вашей организации порядка 200'000 тыс сотрудников, и Вы грамотно распараллелили расчёты по 100 серверам?
- 100 серверов считает з/п для 1880 сотрудников?
- Ваши сервера стоят в 100 организациях по неск. тыс. сотрудников в каждой?Сотрудники распределены по более чем 200-м линейным предприятиям, территориально расположенным по всей России. В каждом линейном предприятии стоит сервер линейного уровня (или один на несколько, территориально расположенных рядом, всё зависит от каналов связи). Есть ещё сервера регионального уровня, они используются для обмена данными между линейными предприятиями (транзакционная репликация) и с них передаются данные в другие оперативные системы и в ОЛАП. Сейчас ведутся работы по созданию центрального сервера в Москве для "глобальной" отчётности. Это я всё упрощённо описал, на самом деле там всё гораздо сложнее. Но вопрос не в этом. Вопрос в другом. Накой писать обработку данных на C++ (C#, Java), когда это можно на порядок проще и эффективнее реализовать в SQL?

Согласен, только на чистом SQL и ХП обработку данных реализовать невозможно. SQL запросы должен кто то толкать и забирать результат и предоставлять его пользователю, SQL это делать не умеет вообще, а ХП с многими ограничениями, т.е. непременно нужен некий клиент БД. А раз есть клиент, то частенько есть возможность разместить расчёты на нём, а не в СУБД. Клиент в данном случае не обязательно GUI компонент или AS. Это может быть некий сервис, например менеджер расчёта зарплаты.

Пример с распределённой системой не показательный. Понятное дело, если раскидать нагрузку по сотне СУБД, то задача будет работать быстро. В данном случае распределённые вычисления необходимы по причине распределённости самого предприятия. Но ведь никому не придёт в голову устанавливать в спортзале сотню серверов СУБД, только для расчёта зарплаты на несколько тысяч сотрудников или чего нибудь подобного. Только на закупку лицензии СУБД на 100 CPU уйдёт куча бабок.

Нужно понимать, что СУБД включает в себя SQL машину, которая решает основную задачу - управление данными на диске, и PL/SQL машину или т.п., которая осуществляет процедурные вычисления (триггеры и ХП). Когда мы покупаем лицензию на СУБД, то платим за оба компонента. Но если мы имеем дефицит только вычислительных ресурсов, при том что SQL машина не догружена, покупка дополнительного узла СУБД или обновление оборудования только ради развёртывания дополнительных расчётов на ХП будет выглядеть несколько странно.

PS. Расчёт ЗП сложен на этапе разработки и внедрения, тогда как на этапе выполнения современный микрокомпьютер справится с расчётом ЗП для тысяч сотрудников в более чем приемлемые сроки. Поэтому здесь нужно ориентироваться на удобство работы с исходником. C++ или Java для этого слишком сложные языки, поэтому естественным выбором может стать PL/SQL и т.п. + GUI на базе framework системы и генератор отчётов.