Bely mcureenabСогласен, только на чистом SQL и ХП обработку данных реализовать невозможно. SQL запросы должен кто то толкать и забирать результат и предоставлять его пользователю, SQL это делать не умеет вообще, а ХП с многими ограничениями, т.е. непременно нужен некий клиент БД. А раз есть клиент, то частенько есть возможность разместить расчёты на нём, а не в СУБД. Клиент в данном случае не обязательно GUI компонент или AS. Это может быть некий сервис, например менеджер расчёта зарплаты.1. ХП может вызываться из JOB-а и записывать данные в таблицу.
Начислили ЗП и записали кому и за что начислили.
А клиент (бухгалтер) посмотрит уже ПОТОМ, когда у него время будет.

2. Сервис - это совсем не трехзвенка.
Это некий модуль сбоку, очень похожий на клиентское приложение, у которого украли пользователя и GUI.

3. Сервис, так же как и ХП, никому ничего не показывает.
Так что аргумент "SQL запросы кто то толкать и забирать результат и предоставлять его пользователю " - не катит.
Сервис это не сможет сделать так же как и ХП.

Всё правильно.

По 1. Чтобы что то посмотреть бухгалтер должен иметь GUI к таблице или получить результат в виде бумажного отчёта. Лично я не видел ХП, которые что то печатают на принтере.

По 2. Сервис это часть трёхзвенки (СУБД, AS это наборы сервисов), но не обызательно трёхзвенка. Cервис может быть прицеплен к системе сбоку или сзади.

По 3. Сервис, может иметь GUI, например управлять тревожной сигнализацией, или бегущей строкой с новостей. Впрочем, это не типичное использование сервисов.

Алексей К mcureenabПример с распределённой системой не показательный. Понятное дело, если раскидать нагрузку по сотне СУБД, то задача будет работать быстроЭто вынужденная мера, было бы возможно, сделали бы всё на одном сервере. Вопрос не в этом. Было утверждение, что при количестве человек более нескольких тысяч, производить расчёт их харатеристик (заработная плата, наработка часов и т. п.) с помощью SQL становится затруднительно. Это не так. Я привел время расчёта для ~2000 работников - ~1:30. Умножаем на 2, получаем ~ 3 минуты. Цифра вполне приемлемая, даже если её умножить на 10. Сервер там обычный - 2 х Xeon 2.4 ГГц 2 ГБ ОЗУ, ну или что-то вроде того, точно его характеристики не помню. Да и с чего бы тот же алгоритм, реализованный на C++ стал бы работать заметно быстрее? За счёт того, что мы напишем Index Seek лучше чем "мудрецы", разработавшие MSSQL? Сомнительно.

Я уже сказал, что в runtime расчёт ЗП сам по себе на современных серверах даже начального уровня в настоящее время не является узким местом. Проблема проявится, когда на сервере БД будут одновременно запущены многие процессы, так что время реакции СУБД начнёт плавать в очень широких пределах создавая проблемы пользователям. Если ЗП расчитывается 1 час, это не проблема. Если в течении 1.5 минут сервер не обслуживает запросы пользователей, это проблема.

Сам по себе C++ не гарантирует увеличение производительности, но он позволяет при сопоставимой скорости получить значительно более богатую функциональность, чем даёт чистый SQL. Да в общем вопрос не в языке, а в виртуальной машине. Java тоже работает не супер быстро, но JVM есть везде, тогда как нормальная PL/SQL машина втроена в СУБД и отдельно не работает.

tygramcureenab, ты все же предпринимаешь попытки оправдать свое незнание PL/SQL в частности и СУБД вообще? Зачем? Это очень .... плохо получается :)

Кстати, попутно еще выясняется твоя проблема с пониманием распределенных вычислений, систем, многозвенок и т.д. Каша какя-то. Уже и не смешно.



Моё незнание PL/SQL в частности и СУБД вообще приносит мне и моим заказчикам неплохие деньги. Может быть я чтото неправильно делаю?

Bely mcureenabПо 3. Сервис, может иметь GUI, например управлять тревожной сигнализацией, или бегущей строкой с новостей. Впрочем, это не типичное использование сервисов.Странненький у вас GUI, однако.
В таком случае - управление RAID-контроллером тоже можно назвать ГУЕм.
Там и лампочка есть, по которой человек может что-то попытаться понять.
А если постараться, то скрипом хардов можно морзянку передавать.

Уговорил. Лампочки на HD, это не GUI. А морянка, это уже мультимедия!

Однако... Если установить 2млн хардов с лампочками в матрицу, то вполне реально получить HD изображение со звуком!

tygraТак мы же не заказчики
Можно найти лохов, вешать им лапшу на уши и раскручивать постоянно на бабки - не спорю, можно, но это умение другого плана :))

А тут не лохи, не заказчики, нас маркетинговыми лозунгами не возьмешь :)

ЗЫ Интересно, а заказчики не считали, сколько экономии было бы, откажись они от распределенных вычислений и перейди на обычный к-с? ;)))

Так я с тебя бабок и не требую.

к-с, это частный случай распределённой системы.

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

Алексей К mcureenabЯ уже сказал, что в runtime расчёт ЗП сам по себе на современных серверах даже начального уровня в настоящее время не является узким местом. Проблема проявится, когда на сервере БД будут одновременно запущены многие процессы, так что время реакции СУБД начнёт плавать в очень широких пределах создавая проблемы пользователям. Если ЗП расчитывается 1 час, это не проблема. Если в течении 1.5 минут сервер не обслуживает запросы пользователей, это проблема.И из-за чего "расчёт зарплаты" должен тормозить работу других пользователей? Исходные данные для расчёта меняться не должны. Значит блокировок не будет. Если оперативки хватит (а её по-хорошему должно хватать), то очереди к диску тоже не будет. Процессора 2, значит все ресурсы расчёт на себя не возьмёт (ну если не распараллелится конечно, но тут всё должно быть продумано). А сейчас вообще уже четырёхядерные процессоры пошли. Если нам не критично время выполнения расчёта, то там можно искуственных пауз навставлять, чтобы другим процессам на сервере больше процесорного времени досталось. Конечно, всё будет несколько медленнее, но такого, что сервер вдруг перестанет отвечать на запросы пользователей случиться не должно. Вариантов решения много, всё зависит от конкретной задачи. И никакой C++, C#, Java и т. п. тут не нужны.

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

2 процессора? 4 процессора? Это в два, четыре раза больше стоимость лицензии на СУБД и оборудование тоже ощутимо дороже. Грубо говоря, вас развели на покупку оборудования и СУБД в значительно большем объёме чем это требуется. При таком подходе, почти все задачи (даже генерацию html страниц) можно решать на СУБД без проблем.

Собственно для посчитать и сохранить ЗП C++ не нужен. Но чтобы распечать отчёты, хоть и не C++, но нужна какая то внешняя программа, хотя бы Web browser.