В моем последнем проекте "Расчет заработной платы", который еще кстати продолжает писаться, используется примерно такая же модель. Если вкратце, то БД логически состоит из 4 частей - входящие данные, описание расчетных обьектов, кэши состояния расчетов текущего месяца и архивные расчетные данные. Часть, описывающая расчетные обьекты, хранит информацию по расчетным обьектам системы, которые могут быть входящими данными, промежуточными расчетами, начислениями, удержаниями и налогами. Каждый обьект может иметь один или множество алгоритмов. Каждый алгоритм за определенный период времени ссылается на хранимую процедуру расчета, причем в понятие периода времени входит 2 даты - дата действия расчета алгоритма и дата его ввода в действие, т.е. фактически поддерживается ввод реализации алгоритмов задним числом. Так же на период действия реализации алгоритма расчетного обьекта описываются его отношения к другим расчетным обьектам, что позволяет построить иеархию расчетных обьектов, определить их правильный порядок расчета и регулировать состояние кэшей (это отдельная система, позволяющая упростить доступ к сложным структурам входящих данных, ускорить расчеты, проводить расчет по требованию и облегчить получение информации для отчетов). Теперь об расчетных ХП, на которые ссылаются алгоритмы - каждая ХП отвечает за расчет одного или нескольких расчетных обьектов, все они имеют некий одинаковый набор входных параметров и обязаны считать по реализуемому алгоритму всех сотрудников, указанных в расчетном буфере (содержит в себе на момент расчета список всех затребованных к расчету сотрудников), у которых этот алгоритм еще не посчитан и заносить результаты расчета в расчетный кэш. Ну и есть центральная ХП, которые вызывает системные ХП, отвечающие за компиляцию изменившихся состояний и взаимоотношений обьектов в специальные карты статусов расчетов, подготавливает расчетный буфер, организует цикл по периодам, подлежащим расчету (текущий месяц, плюс предыдущие периоды, которые необходимо пересчитать задним числом), вызывает ХП, отвечающие за актуальность информации кэша входящих данных, вызывает по подготовленным картам статусов в нужном порядке ХП алгоритмов расчетных обьектов, ну и много чего еще (проверка ошибочных входящих данных, ведение лога расчета, трассировка выполнения расчета и т.д.) Благодаря кэшам такой движок расчетов всегда точно знает, что надо считать, поэтому если повторно запустить расчет, ничего не поменяв в БД, он просто выйдет. Если после проведения расчета на базе 1000 сотрудников поменять у одного сотрудника оклад, то при вызове расчета на всех сотрудников в расчетном буфере окажется только этот сотрудник и ему будет только пересчитанны начисления по окладу, все начисления которые зависят от нач. по окладу и подоходний налог.

Вот вкратце такая система, все к сожалению не опишешь, слишком много всего в ней, но все эти навороты по идее должны будут гарантировать ее легкое сопровождение (все таки целый модуль настройки системы), очень высокую скорость расчетов, облегченный доступ к информации для отчетов и легкость изменения расчетной части при новом изменении законодательства. Я конечно понимаю, что все предусмотреть нельзя, но в принципе система достаточно устойчива к нашим условиям динамики изменения законов.

Я тоже так почему то думал, пока не взялся за проект. Тихий кошмар - сплошные исключения из правил, действует принцип - что в законодательстве не оговорено, значит разрешено, несколько видов алгоритмов расчетов одного и того же начисления в зависимости от условий, для расчетов используются данные как текущего периода, так и с начала года, прошлого года или определенного периода, причем тоже в зависимости от условий. Задним числом могут изменяться не только входящие данные, но и даже алгоритмы расчетов. Плюс куча собственных видов начислений индивидуально для каждого клиента (в моем проекте есть даже спец. движок, позволяющий юзерам добавлять в расчет собственные начисления по библиотеке специальных системных алгоритмов), ну и в каждой отрасли еще свои заморы расчета зп. Если бы я писал сам расчет зп на клиенте, то выглядило бы это как сплошное дикое ветвление. Проект пишется как тиражный, изначально ориентированный на крупные промышленные предприятия и различные отрасли, поэтому так и приходится его наворачивать, в первую очередь учитывая 2 важных характеристики - скорость и гибкость. Естественно все это пишется не для какой-нибудь конторки до 50 сотрудников, где расчет зп сводится к элементарному расчету зп Оклад * Дней.

Во первых у меня перед глазами была постановка старой задачи Расчет ЗП, написанной еще аж на Досовом доисторическом MS Си. Постановка для этой задачи была разработанна очень профессионально, она до сих пор эксплуатируется в различных отраслях - больницах, МЧС, больших заводах, стояла и т.д. Сам проект конечно в силу ограничения используемого инструментария не мог все учитывать, но сама его постановка во многом была удачной. Проект работает более 10 лет, еще остались в конторе люди, пусть и не имеющие прямого отношения к его разработке и постановке, но тем не менее постоянно с ним работающие и сопровождающие его. Такие плюсы помогли мне более менее четко определиться с постановкой задачи, выявить что в старом проекте было удачно, где не очень и самое главное - что не хватает.

Во вторых в технологическом плане построения сложных расчетов у меня имеется достаточный опыт построения систем с сложными или динамически изменяющимися алгоритмами обработки информации (порядка 12 лет) - я писал проекты под зернозаготавливающую и энергетическую отрасли. Начиналось все конечно же с FoxPro на файл-серверных технологиях. В нынешнем проекте используется 2-звенная архитектура клиент-сервер с акцентом всей тяжести логики на сервере - все делает сервер, клиент только обязан организовывать наглядный и удобный интерфейс, с частичной реализацией проверки бизнес-правил достоверности ввода информации там, где это решается примитивным путем. Несмотря на проверку истинности введенной информации на клиенте, сервер всегда реализует полную логику проверки достоверности информации (реализованно в виде ХП - клиент полностью изменяет и удаляет информацию только через ХП посредством кэшированных изменений). Такая модель двойной проверки логики на клиенте и сервере на первой взгляд может показаться избыточной, но на самом деле это позволяет контролировать клиентскую часть, которая пишется не только мной и гарантировать 2 вещи - примитивные ошибки пользователя отсекаются клиентской частью, что не приводит к лишнему обращению к серверу, а ошибки программистов клиентской части отлавливаются серверной частью, что гарантирует истинную целостность БД.

Насчет самого движка - зарплата - продукт, действительно имеющий уникальные, сложные и динамически изменяющиеся алгоритмы расчетов. Наработки у меня уже были, для личных нужд я делал Макрогенератор скриптов SQL, позволяющий писать серии SQL скриптов, в которых допускалось использование макрокоманд управления их сборкой (поддержка команд обьявления и управления переменными, ветвлений, циклов, вставок скриптов, обработка ошибок и т.д.). Однако этот продукт все таки был создан для его работы с клиентской части (написан в виде серии компонент на Delphi, которые реализовали не только само ядро, но и позволяли достраивать язык путем дописания своих компонент команд). Можно конечно было бы встроить макрогенератор в серверную часть, но я решил его в проекте не использовать, так как это привело бы к очевидным неудобствам (хранение скриптов в BLOB-ах со всеми вытекающими отсюда последствиями - необходимость написание собственного инструментария для работы с ними, сложность отладки и т.д.).

Продолжу в следующем сообщении, чтобы легче было читать ... :)

Для движка расчетов я использовал 3 самые элементарные вещи любого порядочного SQL сервера - хранилище данных, хранимые процедуры и динамический SQL. Можно сказать, была разработана обьектная модель расчетов, где любое начисление, удержание или налог приравнивается к обьекту, имеющего один или несколько алгоритмов расчета, способных изменяться во времени, а сами скрипты алгоритмов расчетов (решения) хранятся в виде ХП. Далее в БД зарплаты была описана модель хранения метаинформации этих обьектов и соответствующие ХП, можно сказать внутри БД проекта существует внутрення модель БД движка расчетов. Имея соответствующую полную информацию об иеархии обьектов и ссылки на используемые ХП не составило труда написать ХП, организующую курсор по иеархии и вызывающую через динамический SQL необходимые в ходе расчетов ХП, согласуясь с информацией расчетных обьектов. Фактически получилось, что весь расчет - от и до полностью идет на сервере, клиент вызывает ХП расчета, просто ждет и ходом расчетов он никак не управляет.

Естественно при таком подходе сами принципа расчета не совпадали со старым проектом, в котором применялась горизонтальный расчет, по принципу:
Получается информация по договору
Считаются в зависимости от условий начисления, налоги и удержания
Берется следующий договор ...

В моей схеме сам расчет выглядит так (условно назовем его вертикальным расчетом):
Получается информация по метаструктуре расчетных обьектов (в том числе и по ХП, которые действительны для расчетных алгоритмов на текущий расчетный месяц)
Считаются методом вызова соответствующих ХП по уровню возрастания в иеархии обьектов начисления, налоги и удержания для всех договоров, к которым они применимы.


Сами ХП зависят от сложности расчетных обьектов - например ХП расчета ночных сводится до уровня insert ... select ... , а ХП расчета налога с физ. лица уже посложнее и при работе использует вызовы промежуточных ХП, отвечающих за построение кэшей нарастающих с начала года, налоговых вычетов и материальных скидок. Кстати почти все промежуточные или входящие данные ложатся в специальные таблицы (кэши), хранящие денормализованные текущие входящие или промежуточные расчетные данные. Это делается по 4 причинам:
1. Заполнение и очистка таких кэшей контролируется отдельными ХП, что немаловажно, так как некоторыми промежуточными расчетными данными могут пользоваться более одного расчетного обьекта.
2. Кэши автоматически заполняются и дополняются информацией при их затребовании расчетом и автоматически обнуляются при изменении входящей информации по соотвествующим сотрудникам. Иеархия обьектов позволяет проводить обнуление всех дочерних расчетных обьектов. Все это здорово влияет на скорость расчетов - просчитав данные кэши избавляют сервер от необходимости расчитывать их снова, пока их входящая информация не изменилась.
3. Храня "разжеванную" информацию кэши позволяют алгоритмам расчетных обьектов более легко описывать скрипты расчета, а клиентской и отчетной части элементарным select-ом получать любую интересующую их информацию по входящим и расчетным данным текущего расчетного месяца. Конечно клиент или отчетник перед обращению к кэшу должен вызвать процедуру расчета, которая возможно достроит кэши и досчитает все не расчитанные расчетные обьекты на затребованных сотрудников, но это элементарно решается путем написания для клиента ХП, в которой сначала вызывается проц. расчета, а потом возвращаются нужные данные. Для случаев, когда отчетнику необходимо получить доступ по многим таблицам кэшей, делается одна ХП, которая вызывает расчет, возвращает первый набор данных и блокирует в share-режиме до конца соединения все таблицы кэшей, которые будут использоваться в отчете, позволяя отчетнику далее простыми select-ами получать нужную информацию и гарантировать, что пока отчет не будет достроен, данные кэшей не смогут измениться.
4. Помимо расчетных обьектов в метаинформации системы расчетов еще описываются входящие и промежуточные объекты БД, которые не могут иметь собственных алгоритмов и скриптов расчетов, но на которые могут ссылаться как на родительские расчетные обьекты, что не маловажно для организации правильной очистки кэшей в случае изменения их входящей информации в БД. Что еще более важно, введя в систему расчетов обозначение не только расчетных, но и входящих и промежуточных обьектов, я смог организовать полную расшифровку проводимых расчетов. Такие обьекты имеют собственные ссылки на ХП возврата их состояния в текущем расчетном месяце, что позволяет мне используя иеархию обьектов показать не только суммы начислений, удержаний и налогов, но и значения всех входящих и промежуточных данных, которые были использованны при расчете.

Продолжу в следующем сообщении, чтобы легче было читать ... :)

Очистка кэшей ложится опять же на плечи специализированных ХП, вызывается она естественно из тригеров таблиц, действую примерно по след. схеме:
1.Изменение входящей информации
2. Вызов из тригера соответсвующей ХП
3. Очистка необходимых входящих кэшей
4. Вызов специальной ХП, отвечающей за очистку обьектов в расчетных кэшах, зависимых от указанного обьекта

Так как расчет зп состоит из вызова многих скриптов и работы с множеством таблиц, то он был сделан монопольным - в один момент времени может на сервере выполнятся только один расчет, что абсолютно верно, так как конкуренция в расчетах немыслима, а с учетом использования кэшей, любой вызываемый расчет на момент времени, когда уже запущен другой расчет должен дождаться его завершения и возможно все затребованные к расчету сотрудники будут уже рассчитаны и считать ничего не придется. Все это было реализованно посредством блокировок, где все кэша блокируются в share-режиме, что гарантирует их целостность на момент расчета и блокирует изменение входящей информации, влияющей на расчет, но не ограничивает просмотр данных кэшей. Специальная таблица (лог выполнения и ошибок расчетов) блокируется в exclusive режиме до конца расчета, что гарантирует, что любой другой запущенный позже расчет будет ждать конца текущего, пытаясь ее заблокировать.

Серверная часть изначально писалась на MSSQL 2000, но где то на середине пути (уже когда была готова расчетная часть) по многим причинам была переведена на Sybase ASA 8, о чем я честно говоря не только не жалею, но до сих пор очень и очень радуюсь, опять же по многим причинам.

Клиентская часть изначально начала писаться на Delphi 5, очень я честно говоря очень и очень жалею по многим причинам, но в принципе так как в ней используется множество собственных наработанных компонент, то более менее программировать клиента легко. Так же в клиента встроена вся часть по управлению движком расчетов зп и изменение и редактирование всей его метаинформации.

С учетом того, что сам расчет зп полностью автономен от клиента и написан на ХП, то написание скриптов расчетов ведется с обычного ISQL, в нем же проводится и запуск расчетов и их отладка.

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

Первый (некешированный) расчет зп за месяц для 1000 сотрудников сейчас занимает на Athlon XP1500 порядка 8 секунд. Последующие вызовы расчетов по времени зависят только от степени изменения входящих данных и колеблются от 0 (все посчитано) до 3 сек (частичный пересчет недостающих данных).

Вот вроде и все о системе. Не смотря на то, что у меня при такой модели проектирования БД нашлось немало скептиков, утверждающих, что при таком сложности и ветвлении расчетов их можно реализовать только на клиенте или 3-звене, можно сказать я им доказал, что любой современный SQL сервер при правильном подходе и проектировании БД может полностью и самостоятельно проводить всю обработку информации. Думаю если все будет нормально и мне ничто не помешает дописать и запустить свой проект, наработок в копилку опыта построения сложных систем прибавиться и может быть мне удастся все таки отойти от бухгалтерии и заняться более интересными делами, например разработки собственной системы абстрактного моделирования данных, благо теорию по ходу написания зп прорабатываю и тестирую на конкретно пишущемся проекте ;)

P.S. Ну и тем кто дочитал все это до конца, приношу извинения за грамматические ошибки и запутанные обьяснения - писал долго, ночь на дворе и голова уже плохо варит :)

aag
Угу, Вы все поняли правильно. На каждый входящий обьект в модели БД существует одна или серия обычных нормализованных таблиц, хранящих входящие данные, с которыми и ассоциируется этог обьект. Плюс на каждый входящий обьект существует собственные ХП очистки и заполнения соотвествующего кэша. В итоге при изменениях в модели данных БД вызываются тригера, которые заполняют соотвествующую темповую таблицу с перечислением изменившихся данных, далее вызывается ХП очистки соотвествующего кэша, в которой очищается завязанные на входящем обьекте кэши и вызывается универсальная ХП очистки расчетного кэша, в которую передается Имя обьекта (помимо ID все обьекты системы имеют уникальное имя - например Ставка, График, Табель, НалогВычет и т.д.) и список сотрудников, у которых состояние обьека было изменено . Сама процедура по иеархии обьектов вычисляет все зависимые от изменившегося расчетные обьекты и удаляет из из расчетного кэша. В итоге при следующем пересчете удаленные с кэшей данные будут автоматически пересчитаны.

При таком подходе унификации параметров процедур для обработки входящих и межрасчетных кэшей не требуется, так как вызываются они вручную с тригерров и ХП расчетных обьектов. Сами же ХП расчетных обьектов действительно идентичны по принимаемым параметрам, так как вызываются из динамического SQL в цикле курсора, причем имеют параметры общего плана - расчетный месяц, текущий расчитываемый месяц (на случай расчета задним числом), код обьекта и алгоритма, к которому принадлежит ХП и флаг отладки (для вывода трассировки командой Print). Все остальное делает сама ХП алгоритма расчетного обьекта, фактически являясь автономной от расчета. Единственное что ей требуется для запуска - это вышеперечисленные параметры и заполненные расчетные буфера, содержащие на момент расчета список затребованных к расчету сотрудников. В кач-ве примера привожу скрипт ХП расчета подоходнего налога (написано на WatcomSQL):



Как видно, в самой процедуре управления транзакциями нет, так как она запускается из центрального расчета, который их и организует и отслеживает. Так же нет и обработки ошибок (в MSSQL 2000 была), так как в ASA существует механизм Exception-ов, позволяющий в ходе выполнения транзакции на автопилоте осуществить откат транзакции и прерывание выполнения процедуры. В центральной ХП расчета стоит блок отлова ошибок - exception, позволяющей ей обрабатывать и логировать возникающие при расчете ошибки (в ASA это реализуется через атомарный блок).

При написании скриптов расчетов различных начислений, удержаний и налогов проблем не возникло, все отлично вписалось в существующую схему работы. Даже больше того - такая схема расчета и хранения данных текущего расчетного месяца в кэшах позволила мне довольно элементарно решить не самую легкую в зп часть - организацию межрасчетных выплат и аванса, которые могут выдаваться сотрудникам до окончательного расчета зп и несмотря на это могут ссылаться на данные расчетов. Например в середине месяца необходимо выдать всем сотрудникам начисленную премию, которая расчитывается как 50% от отработанного времени (то есть от реально посчитанной суммы начисления по окладу, а не самого оклада) и заодно удержать с нее подоходний налог. Далее при окончательном расчете все это тоже должно быть учтено, что премия уже выдана, что часть налога снята. Или же еще более забавный случай - сотруднику выдают аванс, потом межрасчетной выплатой премию, далее он сразу уходит в отпуск и неплохо бы досрочно посчитать окончательный расчет и выдать ему все оставшиеся деньги на руки. При окончательном расчете, когда сотрудник уже будет отдыхать на море все будет учтено и на руки ему пойдет сумма 0.00 . Со всеми этими наворотами движок прекрасно справился и режим межрасчетных выплат и аванса был сделан всего за 4 дня (серверная и клиентская часть).

Про Delphi 5 лучше ничего говорить не буду. Обычное RAD средство, глюков правда многовато. В принципе не намного лучше или хуже аналогичных сред. Пожалел я в другом плане - что под клиента не выбрал Power Builder, на котором клиентская часть писалась бы гораздо легче, безглюкавей и ее было бы в последствие легче сопровождать. Но к сожалению когда я стартовал этот проект (январь 2002 года), PB я только увидел (к стыду своему) и естественно не зная насколько он хорош и рисковать не мог. Поэтому и была взята Delphi 5, раз уж я на Delphi порядка 8 лет программировал, имел кучу компонент и наработок. Сейчас конечно, когда я уже достаточно изучил PB, поделал на нем мелкие проектики, наработал собственные решения, очень жалко, что я его никогда не видел раньше, так как мое личное мнение, что при правильном подходе проектирования программ PB является на текущий момент самой перспективной и удачной средой разработки клиентских приложений.

Так поэтому все и в ХП, что 3-звено для такой задачи абсолютно бесполезно. Я вот в своей жизни много раз слышал, какое это все таки замечательное 3-звено, как на нем все красиво и удобно и какие замечательные возможности оно открывает. Только вот ни разу не видел, чтобы приложения с 3-звеном действительно были так не требовательны к серверам и действительно позволяли играючи перевести работу с одного сервера БД на другой. Зато я достаточно насмотрелся на лишнюю дублирующую работу, запутанность со временем классов 3-звена и способы его работы методом курсорных переборов записей. Если Вы думаете, что на 3-звене сможете быстро и легко реализовать расчет зп, который будет иметь изменяющиеся со временем алгоритмы расчетов и все это будет быстро работать, то очень и очень сильно верите в эффективность 3-звена. Думаю мои 8 секунд расчета 1000 сотрудников выйдут Вам на 3 звене не меньше 3 часов машинного времени. Для сомневающихся достаточно запустить любую курсорную зп, ту же 1С и посмотреть, как быстро все считается.

Насчет вывода зарплаты в WEB это оригинально - наверное полезная фича для печати в интернете данных по зп сотрудников. В текущей постановке задачи я такого требования не видел.

Интеграция с другими системами очень даже элементарна - думаю ODBC и ADO никто не отменял и любая система может получать доступ к данным БД и вызывать сооствествующие ХП. То же относится и к обратной связи - ASA спокойно может подключать удаленные сервера и работать с их таблицами и ХП. Причем тут файлы "фокспра" я не очень Вас понял. Если Вы не о DBF, то желательно уточнить о чем речь.

Ну и последнее - в кач-ве сервера СУБД используется Sybase ASA 8, с 1 лицензией стоящий порядка 500 долларов и требующий в минимальной конфигурации Pentium-1 166 и 4 MB RAM. Ну очень хочется посмотреть на заказчиков, которые одному-двум бухгалтерам расчетчикам зп будут ставить зарплату на Оракле, чтобы наверное потом легче было сопровождать и администрировать :)

c127
Изменение алгоритмов расчета поддерживается на довольно простом и элементарном уровне - в метаинформации системы расчетов на каждый алгоритм за определенный период времени указанна ХП, которая реализует для данного периода алгоритм расчета. То есть из примера ХП, что я привел, ее название sp_Calc_Object_20020101_20020101_ПодоходНалог можно расшифровать так:
Имя обьекта: ПодоходНалог
Дата ввода в действие: 2002/01/01
Дата начала периода действия: 2002/01/01

Соотвествующе со следующего года у нас изменился расчет подоходнего налога, т.е. не процент или налоговая таблица, что в справочниках можно поменять, а именно сам алгоритм. Пишем новую процедуру sp_Calc_Object_20030101_20030101_ПодоходНалог , что означает:
Имя обьекта: ПодоходНалог
Дата ввода в действие: 2003/01/01
Дата начала периода действия: 2003/01/01

Далее все просто - текущий расчетный месяц декабрь, все считается по первой ХП, перешли на январь - по второй ХП. Но ... например в январе происходит сторнирование декабря у сотрудника (что то изменили задним числом). Что получается - система для данного сотрудника сначала посчитает декабрь, причем налог будет считаться по 1 ХП, далее будет расчитан тек. месяц январь, где налог уже считается по 2 ХП и к нему прибавлена разница между декабрем что было и что стало в результате пересчета.

Более интересный пример - существует ХП, отвечающая за расчет отпуска и действующая с 2002/01/01 . Все по ней прекрасно считается до июня 2003 года, когда выходят изменения в трудовом кодексе, гласящие, что с 1 января 2003 года отпуск считается совсем по другому. Пишем новую ХП по расчету отпуска на нач. периода действия 2003/01/01 и датой ввода в действие с 2003/06/01. Что получилось - входящие данные БД не изменились, однако изменение задним числом алгоритма расчета отпуска приведет к тому, что все сотрудники, ушедшие в отпуск с января по июнь будут пересчитаны задним числом.

Насчет отладки SQL-кода - опасения напрасные. Каждая процедура расчета довольно таки автономна и вызвав соотетствующую процедуру заполнения расчетного буфера я спокойно могу их запускать отдельно, вне расчета и смотреть на результаты выполнения. Существует в Sybase ASA 8 и отладчик, который по удобству и возможностям ничем не уступает отладчикам современных языков программирования. Однако пользоваться им как то особо не приходится. Select в отладчике и останется Select-ом, с учетом того, что у меня дополнительно в БД куча вьюверов и кэшей, облегчающих доступ к сложной информации БД, то select-ы на самом деле неплохо читабельны. Еще в ASA есть довольно замечательный profiler, который позволяет мне фиксировать вызовы ХП, их общее время выполнения и процентное соотношение во времени, позволяя детализировать ХП прямо по ее листингам, по строчкам показывая, что и сколько времени выполнялось. Так что узкие места в расчете ASA показывает очень в удобном и наглядном виде.

sparrow
8 секунд на самом деле моя гордость :) Ни в одной зп так быстро считься не будет, время будет всегда измеряться в минутах только по той самой простой причине, что у меня расчеты выполняются вертикально по расчетным обьектам, а не горизонтально, по сотрудникам, что и реализовано в большей части зарплат. Тесты с 100 000 сотрудников я конечно не делал, так как таких больших контор с таким кол-вом сотрудников в России я себе вообразить не могу. Но думаю, что говорить о линейном возрастании времени при увеличение кол-ва сотрудников стоит только в отношении горизонтальных, ну или проще сказать курсорных расчетов. Доказать очень легко - в курсорном расчете увеличение кол-ва сотрудников приведет к увеличению выполняемого цикла расчета по сотрудникам. В моем варианте длина цикла равняется не кол-ву сотрудников, а кол-ву расчетных обьектов. Сколько бы мы сотрудников не имели, у нас как было например 50 начислений и 10 удержаний, так и осталось. Получается выполняется 60 не сложных SQL скриптов, пользующиеся разжеванными данными из кэшей по принципу:


Думаю увеличение кол-ва записей в select-ах не приводит к линейному увеличению времени выполнения запросов в любом SQL сервере. А с учетом кэшей проблема отпадает сама собой. Постоянно работая с сотрудниками, вызывая многие режимы и отчеты даже до окончательного расчета расчетчики зп неявным образом очень часто для клиентской части строят кэши и вызывают неявные расчеты по требованию клиентской части. Так что получается во многом в фоновом режиме система на автопилоте строит свои кэши и производит расчеты, что конечно же увеличивает скорость выполнения окончательного расчета. Так что если я Вам покажу расчет зп 100 000 сотрудников за секунду, не верьте мне, что ASA супер-быстрый - просто кэши полные :)

Кстати насчет супер-быстый - парадоксально, но факт - после перевода БД с MSSQL 2000 на Sybase ASA 8 теже самые запросы и ХП на тех же самых данных стали выполнятся как минимум в 3 раза быстрее. Это при том, что больше 8 мб РАМа ASA у меня не кушает. Такой вот SQL сервер для рабочих групп :)

Gt_
Обдумал вот на досуге, решил ответить.

Насчет начальства на Кипре это зря - зарплата закрытая система и никто кроме расчетчиков бухгалтеров, кстати своей шкурой отвечающих по всей строгости закона за ее расчет, ничего там смотреть и уж боже упаси менять не может. Если предприятие большое, то отделы прикрепляются к определенным расчетчикам и они и только они уже могут работать с информацией расчитываемых ими отделов. Так что никакого WEB-а однозначно. Вся информация с зп все равно потом естественным образом экспортируется в бух. системы, вот оттуда общие цифры начальству и требуется поглядеть. Но это уже не проблемы зарплаты. Ну а черную зп если наша контора и решится прилепить к системе, то только отдельным модулем, и пусть хоть с Кипра ее все смотрят, если на то пожелание клиента будет. Тем более что расчет черной зп элементарен - берем сумму, оговоренную начальством, отнимаем от нее сумму на руки, полученную в зп, остаток денег и есть черная зп сотрудника. Это и калькулятором при желании сделать бухгалтеру не долго. А вот отпусные, больничные или соц. налоги калькулятором не посчитаешь, раньше наверное свихнешься.

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

Еще вариант, в котором использование 3-звена может быть оправдано - это удаленная работа пользователей с данными. Для данного проекта этого быть не может - зп всегда считают в одном месте, если у конторы есть филиал, то там будет и свой расчетчик зп и опять же на месте он будет ее считать. Пересекаться БД конторы и филиала не будут - у каждого своя отчетность, своя налоговая и частенько свой банк.

Теперь насчет Си и его быстроты. Чуть выше у меня в кач-ве примера приведен SQL скрипт ХП расчета подоходнего налога, не очень кстати сложный и большой. Если Вы сможете на Си реализовать логику, которая будет позволять делать то же, но быстрее, чем запрос на ASA (движок кстати которого делали Watcom-овцы), в котором не кислый оптимизатор запросов, то значит Вам пора давно работать в командах по разработке SQL движков. Если Вы будете перелопачивать на 3 звене данные курсорами, то просто загрузите компрьютер, сеть и сам сервер БД сотнями запросов к БД и циклами переборов записей. Быстрее не будет - это уж точно :) Если же Вы на 3 звене вызовите скрипт, аналогичный моему с ХП, взятый откуда нибудь из BLOB-а, то возникает закономерный вопрос - а зачем тогда это 3-звено нужно, если и ХП прекрасно справляется с той же задачей, вернее даже лучше справляется, так как посылая скрипт с 3-звена на сервер Вы получите дополнительным бонусом время компиляции плана выполнения этого скрипта на сервере, а ХП уже лежит откомпиленная, да еще и со статистикой.

Еще одна приятная особенность использования всей логики в пределах БД - автономность. Чтобы запустить расчет, получить нужные данные, произвести некоторые действия над данными или же экспортить или импортить их куда то мне требуется только СУБД. Ни клиент, ни 3-звено, ничего не нужно. Заходим в ISQL, пишем call sp_Calc_Object_All ( 0, 1 ) и запускам расчет по всем сотрудникам с трассировкой хода выполнения. Очень удобно кстати для разработки и отладки.

Думаю все понятно. Конкретных и весомых причин для использования 3-звена и в данном проекте я не нашел. Честно говоря, сколько я не видел программистов, нахваливающих 3-звено, частенько на поверку оказывались люди, которые не сильно знают SQL и предпочитают по старинке курсорчиком все данные перелопачивать. Конечно это не обо всех, кто пишет на 3-звене, но вот многовато я проектов видел с использованием 3-звена, для применения которого я в этих проектах обоснования, кроме как незнания SQL систем не видел.

Gt_
не вижу никаких проблем с запуском обыкновенного sql из мидл тиер
А зачем запускать sql-скрипт из 3 звена, если он прекрасно из ХП запускается ?

еще раз - если хп может обойтись sql, без циклов - то же самое делаем на мидл тиер. зато на мидл тиер у нас больше памяти (не нада с СУБД делится) и процессор посвободней
Добавляем сюда опять же вышенаписанный вопрос, плюс еще вопрос - о какой памяти и процессоре идет речь, если 3-звено будет просто посылать запрос SQL серверу ? Это так много памяти кушает и занимает процессорного времени ?

сдесь не понял ... а какие планы у хп ? я правда только с ораклом работал ... но мне казалось планы и оптимизатор - фича sql запросов, откуда они приходят из хп или с клиента СУБД неважно
Хех - признайтесь честно, Вы наверное с Ораклом тока с 3-звена работали :) Вообще то у любого сервера СУБД план выполнения ХП или вьювера сохраняется в БД, чтобы его не компилить каждый раз, кстати для очень длинных ХП, которые еще часто и вызываются это очень актуально. Плюс еще есть статистика по таблицам, в которой содержится среднее процентное попадание данных по индексам и без нее нормальный план оптимизатор не построит и ХП при создании плана на нее ориентируется, что опять же для обычного запроса будет занимать каждый раз время.

пройти по громадному курсору и выполнить сложную логику, которую в sql не запихнуть
Да - согласен, есть логика, которую в SQL прокручивать бестолку, например сложные мат. расчеты или вычисления. К бух. системам это конечно отношения никакого не имеет, но ведь на СУБД не только бух. системы пишутся. Но и тут прекрасно можно без 3-звена обойтись - на данный момент любой СУБД поддерживает расширенные ХП, на которых эти мат. расчеты организовать и можно. К примеру ASA полностью интегрирован с Java, достаточно создать свои классы, написать там обработку любых сложных расчетов и спокойненько пользоваться этими классами, прямо из ХП. Если же у Вас не только сложные расчеты, но и так же хранятся сложные данные, не подходящие для хранения в релляционном виде, то никто не мешает написать классы с нужным функционалом, которые сами данные и хранят и спокойно в таблице организовать поле с типом написанного на Java класса. Далее все делает ASA - хранит экземпляры класса, позволяет обращаться к ним из SQL скриптов и ХП, позволяет вызывать методы класса. Если захочется сделать распределенные вычисления, так никто RMI в Java не отменял :) Расчеты можно и на другом компьютере с запущенной Java-машиной производить.
По моему вполне достаточно, чтобы реализовать функционал любой сложности.

P.S. Кстати насколько я слышал, в ASA 9 таким же образом будет интегрированна еще и с .NET, так что по идее все желающие смогут катать свои ХП на том множестве языков, которое предоставляет .NET (хе хе - ХП на Фортране). Хотя честно говоря не видел и не знаю - правда это или нет.