Моделирование нагрузки

[DUCKKK]

Сколько же гениев пропадает .... Вот бы их в разработчики (мечтательно).

[GIN]

не понял смысла сарказма)) или это констатация?

поддержал тему, высказал мнение, хотя задачи у меня такой не стоит - если есть что сказать, то прошу яснее выражать, обидеть, расстроить или что то ещё, меня вряд ли Вам удаться, так что, не боясь можете высказывать, всё что Вы думаете. Ждемс Вашего веского
_________________
Что бы увидеть свет в конце туннеля, нужно все время копать...

[DUCKKK]

Да я не собирался никого обижать. что Вы. Я восхищаюсь.

[Antoshes]

А мне вот интересно, если в базе 50 000 человек, это ж какой штат Расчетчиков и ОТиЗок с Кадровиками должен быть ?
Может проще будет бизнесу на отдельных серверах вести расчет и реплицировать данные?
Думаю, нет смысла гнаться за скоростью расчета на одного работника. А вот использовать новые технологии СУБД, наверно стоит.
Ждемс!

[DUCKKK]

+1 к гениям .. Кто ещё?

[Volod]

2 Antoshes
Согласно заявлениям БК 1 расчетчик может рассчитывать примерно 3000

А решение с расчетом и репликацией данных на отдельных серверах всё равно не позволит сократить штат пользователей указанных выше, да и решения с отдельными серверами и репликацией есть у 1С которая стоит намного дешевле чем БК да и IT спецов, расчетчиков и ОТиЗок с кадровиками знакомых с 1С найти в разы проще.

[GIN]

Почему же? Есть решения облегчающие объем такой работы, нормы на 1 расчетчика только и существуют для того, что бы их обходить. Этими решениями возможно не только сократить штат, но и не увеличивать его при растущем количестве сотрудников.

И что это за скрытая реклама?

[Volod]

Объем какой такой ?
Ведение кадровых данных, учет рабочего времени, больничные, отпуска ?

Никакой скрытой рекламы.

[Joenka]

Пример:
Росгостарх, около 500 тыс. работников :
Ежемесячно, по всем сотрудникам безопасники присылают файл с проходами через турникеты.
Все просто, данные грузятся в SQL базу (сервер надо заметить очень слабый в отличие от кадрового с Oracle БД), затем обрабатываются пары "вход-выход" и рассчитывается время пребывания на работе. Делалось все обычными циклами и расчет составлял примерно 2-е суток.
Ваш покорный слуга оптимизировал алгоритм с циклов на запросы и временные таблицы. Результат: Расчет занимает примерно 20-40 минут.

Теперь к расчету зарплаты в БОСС-е. Мы проводили исследования и анализировали логи Profiler. И я могу сказать с уверенностью и с долей сожаления, что оптимизировать там нечего Все запросы простенькие, все insert update delete в одну строчку Именно 1-3 секунды на расчет сотрудника уходят из-за особенностей языка, который при запуске цикла обращается к SQL серверу и тратит драгоценное время.
Не верите? Создайте произвольный отчет в БОССе и туда цикл на 1000 операций - в цикле сделайте Alias s:='Вася' или i:=i+1 ну что угодно. Только до цикла в переменную время запишите и по окончанию цикла и сделайте return - удивительно, не правда ли? Цикл на 1000 операций около 5 секунд.
Для примера, в том же VBA напишите цикл на 100 000 операций и вуаля - секунда.
А все почему? Все просто, ведь каждая операция цикла не важно какая, даже если эта операция ну никак с SQL не связано, все равно в Profiler-е проходит! В частности i:=i+1 в профайлер выглядит как select 1 - чудеса!

[Antoshes]

Joenka
Вы пишите про X - язык ,а в расчете используется Z.
Циклы по расчетной таблице не преобразуются в запросы к серверу.

[Joenka]

[GIN]

[Volod]

Безусловно, но при чем тут репликация?
Я из написанного вами так и не понял.

[GIN]

я о ней вообще слово не говорил и она ничего не решит скорее всего...
_________________
Что бы увидеть свет в конце туннеля, нужно все время копать...

[DUCKKK]