laleks
6. Поскольку зарплата - конфиденциальная вещь - делать на нее отдельную БД со свом доступом.
Обшие справочники можно размещать в отдельной БД.

Всё это в лёгкую делается с помощью видов. Я у себя так и реализовал.

Алексей К
Я привел время расчёта для ~2000 работников - ~1:30. Умножаем на 2, получаем ~ 3 минуты.

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

Алексей К
Ну если 2000 сотрудников обсчитываются где-то 1.5 ... 2 минуты, то один - "мгновенно". Лицевой счёт сотрудника с различными расчётами нарастающим итогом с начала месяца по первичным данным открывается где-то секунды за полторы.

Так это нормально, это и есть работа в режиме реального времени. Это когда после ввода данных, бухгалтер видит результаты расчёта и сразу проверяет правильно ли произведён расчёт и если ОК, то можно смело переходить к следующему л/с.
С такой скоростью работы системы нам удалось свести количество ошибок фактически к нулю, при этом каждый бухгалтер ведёт 600-700 чел, а на время болезни или отпуска одной, ещё больше.

mcureenab
C++ слишком сложный язык для описания алгоритма расчёта зарплаты, а это скорее самый важный критерий.

Нормальный язык, для такой задачи не сложнее других, у меня клиентские части написаны на C++ Builder. И я ни сколько не жалею, что выбрал этот язык прграммирования. Все расчёты как я уже отмечал сводятся к простым простым арифметическим действиям. А вот придумать как реализовать эту задачу и как всё это разбить на сравнительно простые куски, вот это действительно не просто.

mcureenab
2, 3. ХМ. А чем select, insert, update, delete не устраивает? Тем более что компоненты доступа к БД, эти запросы самостоятельно создают. И триггеры никто не отменял. А >50 строк, так это может быть так пользователю надо. Другое дело, если пользователю много строк не надо, то нефиг их тянуть все.

При получении запросов select, insert, update, delete сервак:
1: сначала призводит синтаксический разбор текста
2: затем компилирует
3: производит оптимизацию плана запроса
4: и только после этого выполняет сам запрос.
При использовании ХП, первые 3 пункта выполняются после изменении текста ХП, а при вызове сразу пункт 4, при этом при экономятся ресурсы сервера, и выигрыш от этого бывает очень значительный.

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

А сколько строк тянуть на клиента? Конечно лишего не надо, тут даже и спорить нет большёй необходимости. Хотя если делать курсор на сервере и тащить только 5 записей например из полученных 500, то остальные останутся на сервере и будут отнимать его ресурсы (временное пространство не резиновое). И поэтому иногда выгоднее всё же их утащить на клиента и там делать многократный перебор этих значений.
В ADO напрмер, можно реализовать курсор как на сервере так и на клиенте, всё зависит от каждого конкретного случая...

Алексей К
Да действительно, бывает полезно сразу после ввода данных отобразить оператору какие-нибудь расчётные характеристики, основанные на вновь введённых данных, чтобы он смог оценить правильность ввода.

Да не просто полезно, а необходимо, без этого не будет хорошей скорости работы системы, а это лишние рабочие места, компьютеры, лицензии на ПО и другие затраты...
Это если грубо сравнивать, когда например автомобиль начинает разгонятся после нажатие на газ с заметной задержкой и также и тормозить, на таком авто быстро не поездишь и много не заработаешь.

Bely
Группировка, аналитика и джоины - всех на клиента!
Не барское это дело данные обрабатывать...

Вот это я не понял, как будет всё это клиент делать? Он ведь абсолютно не владеет языком запросов!

Bely
Языком запросов владеет программист, а сервер и клиент выполняет инструкции

По поводу того, что клиент не умеет выполнять SQL запросы - тоже не верно.
Вспомните, хотя бы, старый добрый Access.
Запросы выполняет, работает полностью на клиенте.

Дело в том, что большинство запросов проще выполнить там же где лежат данные, чем передавать данные в отдельную программу.
Именно это и делает СУБД.

Ещё раз повторюсь, SQL запросы выполняет всё же SQL сервер, а не как не клиент ... А программист просто знает как работают запросы.

На сколько я правильно помню, старый добрый Access запросы всё же выполнять не мог, их за него выполнял механизм Jet. А почему всё это работало полностью на клиенте. Всё очень просто, при инсталяции офиса, Jet автоматом садится. И при работе с ADO рекомендуют выбирать для работы с MDB именно Jet с ним выше скорость, и поэтому функции он может выполнить которые есть только в Access.

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

B MSSQL так же...
С Oracle много схожего, хотя у каждой БД есть свои изюминки, которой нет у другой.

mcureenab
Хех. Что, без SQL уже посчитать ничего не умеем? SQL запрос в конечном итоге сводится к выполнению определённого алгоритма, который при желании можно запрограммировать на алгоритмическом языке. Совсем не обязательно загружать массив чисел в БД, чтобы посчитать сумму его элементов.

И без SQL посчитать умеем, и даже лучше чем он, например при сложных научных расчётах...
Вообще то БД это в первую очередь хранилище данных. Будут данные, будет что обрабатывать...
Наибольшая скорость работы SQL серверов заточена как раз на выполнение запросов, к примеру с помощью серверных курсоров, суммирование будет гораздо медленней чем простой select.
А если массив чисел находится на клиенте, то это не наш случай. Дебаты идут по вопросу, качать данные с сервака на клиента и например там суммировать, или суммировать на сервере...

serjio-k
Если же быть серьезным, вынос вычислений на отдельный сервер - не самая плохая идея. Виртуальная машина PL/SQL действительно медленная...

А зарплату надо считать в 1С :) Это была провокация.

Ситуацию когда процесс вычислений на HP SuperDom с PL/SQL, выносили на отдельный сервер с C/C++ я встречал. И при этом получали заметный выигрыш в скорости. Но это очень редкий случай.

А про то, что зарплату надо считать в 1С : Это не провокация.
Пусть поделятся опытом кто на предприятии численностью в тысячи человек, внедрил расчёт зарплаты на 1С, как скорость работы, на каком железе, ну очень интересно...
На сколько я в курсе например "Камин", рекомендуют до 1000 человек, а реально до 500.

mcureenab
Что тут дебаты разводить. Тупая задача, тупое решение.

Прежде чем задачу называть тупой, неплохо бы её самому решить и поделиться своим опытом.
А тупое решение может быть у любой задачи, гораздо сложнее найти хорошее решение!

mcureenab
Гораздо интереснее, когда нам нужно и агрегаты поиметь и детализацию...

В это не понял? Как раз с этим то проблем и нет.

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

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