В моем последнем проекте "Расчет заработной платы", который еще кстати продолжает писаться, используется примерно такая же модель. Если вкратце, то БД логически состоит из 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 (хе хе - ХП на Фортране). Хотя честно говоря не видел и не знаю - правда это или нет.

Хорошо - немного флейма в данном деле не повредит :)

Буду Вас разбивать по пунктам:
а) мой любимый язык
личные предпочтения в работе недопустимы

б) он ООП
ООП хорош для работы с иеархиями обьектов, но вот для работы с множествами он скатывается до примитивных алгоримов.

с) я на нем могу все, а что немогу мне помогут ... а вот спецов по ораклу ...
я на очень многих философиях программирования могу все, начиная от машинного кода, ООП и SQL ... но лучше все такие при выборе руководствоваться целесообразностью применения технологии. Избитая фраза, но к месту - на ассемблере тоже можно все ... но вот сколько труда то ...

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

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

Насколько я понимаю основные различия разработчика проектов и кодера как раз и заключаются именно в том, что разработчик проектирует задачу, потом кодеры с соотвествующей уровню сложности задачи и выбранными инструментами реализовывают ее части. Я параллейно курирую проект "Дизайнер моделей обуви". В данном случае в нем задействованны люди, ничего не знающие об SQL, но очень хорошо плавающие в ООП и графическом моделировании обьектов. Но подключить к своему проекту я бы их не смог по той простой причине, что ничего о принципах релляционных БД они не знают, их знания заканчиваются на уровне SQL92 и ограничиваются простыми запросами. И я не сомневаюсь, как бы они стали писать проект.


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

>>>Печатаем нужные ведомости, отвозим их в банк.
ну конечно тоже вариант :) а экспортировать - кто этим будет заниматся ? а банку такое нада ? у банка есть xml-gateway и грит на работай, нехошь не работай ...

Все в одну корзинку ... любой проект не может писаться по принципу "возможно все". Каждая логическая часть функционала проекта должна быть обоснованна и спроектированна с учетом постановки задачи. Делается по разному, но в любом случае описание бизнес-процессов проекта необходимо (хоть ручками, хоть в BPWIN). Рядышком кстати в этом форуме такая тема живет и процветает :) Нельзя решить задачу без четкого описания и понимания ее сути. В моей ЗП по постановке задачи четко и явно разграничиваются права и привелегии пользователей, кто что может видеть и делать. То же относить и к банкам - без ведомости с подписью главбуха банки не имеют права выдать по счету зп организации деньги или же перевести их на кредитные карточки. Так же как например и организация не имеет права хранить полученные от банка деньги на выплату зп более 3 дней. Не выдали - значит обязаны сдать обратно в банк, опять же с соотвествующими бумажками. Все описано и регулируется законодательством РФ, вот когда оно поменяется, тогда будет выпущена новая версия продукта с новой реализацией соотвествующей логики.

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

Думаю флейм насчет 3-звена надо закрывать. Лучше я, если будет время, еще парочку решений сюда напишу, применяемых мной впервые, если кому интересно. Это реализация поддержки и обработки деревьев иеархии в БД, на которых держаться сами расчетные обьекты, плюс поддержка множественного наследования, на этом принципе сделаны расчетные маски, которые обозначают группу начислений и могут наследоваться от одного или нескольких родителей масок. Плюс могу описать реализацию хранения фактических отклонений значений обьектов от плановых значений - таким образом у меня реализована схема хранения учета табельного времени сотрудника, которая позволяет вместо того, чтобы на каждый день хранить информацию о сотруднике (что делал, сколько работал), хранить только отклонения от установленного ему плана работы, что приносит довольно таки ощутимую экономию пространства БД (к примеру допустим на 1 000 сотрудников храним 30 дней месяца: 1 000 * 30 = 30 000 записей в месяц, в моем варианте график для работы этих сотрудников расписан на 30 дней - 30 записей в кэше графиков, из 1 000 сотрудников 100 имели отклонения от плана работы, например бастовали 5 дней, вместо того, чтобы работать - в итоге 100 * 5 = 1000 записей). Результат на лицо. Причем для всех частей системы, в том числе клиентской и отчетной через ХП и вьюверы будут возвращаться полная раскладка дней их работы в месяце. Ну и еще много наверное чего в кач-ве паттернов сюда пописать можно ... было бы время и желание :)

Ну вот я и добрался до дома :) Бум отвечать по порядку.

aag
Ведение истории есть. По ФИО не ведется, так как в самой постановке задаче это не востребованно. В тех же частях, от которых зависят расчеты и отчетная часть история обязательная часть проекта (например история изменения тарифной сетки, подоходнего налога, налоговых вычетов, учета табельного времени, наименования и значения кодов дохода и т.д.). Там, где данные могут изменяться задним числом история ведется с учетом изменения задним числом. Как ни странно, но по постановке фактически в 80% случаев требуется история изменения информации, из них 50% с учетом изменения задним числом. Причем в некоторых случаях даже смешно получается - например как оказалось дата увольнения задним числом сотрудника очень даже часто встречающаяся вещь в мире расчетчиков зп. Проект я бы не сказал, что сильно усложнен, так как на ведение истории на любую часть данных и особенно задним числом, я очень тщательно взвешивал все за и против, консультируясь с постановщиками, сопровожденцами и клиентами и анализируя все случаи уникальных отклонений от постановки. То есть грубо говоря при проектировке я старался задействовать только общие случаи, чтобы реализовать частный случай какого то усложнения в системе народу приходилось очень долго мне обьяснять и доказывать, что он востребован. Далее с учетом архитектуры БД если отклонение было единичным случаем в практике сопровождения старого проекта заработной платы и при желании его всегда можно было дописать в систему, не изменяя архитектуры, я фиксировал у себя как возможно не решенную проблему дополнительного характера и пропускал ее реализацию. Иначе проблема приравнивалась к блоку основного функционала, проектировалась и реализовывалась в архитектуре БД. Для поддержки в системе данных с историей существует 2 типа вьюверов - возвращающие информацию на текущий расчетный месяц и возвращающие информацию на указанный расчетный месяц (в MSSQL эту функцию выполняли UDF, в ASA UDF не могут возвращать набор данных, зато есть поддержка глобальных переменных и вьюверы могут на них ссылаться. Я их для удобства называю параметризированными вьюверами).

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

Такой вьювер стабильно вернет последние значения всех действующих ставок на текущий расчетный месяц, учитывая момент, что они могли быть изменены задним числом. Поле WorkDate означает начало действия тарифа, SaveDate месяц его ввода, в кач-ве конца этих дат выступают более старшие по времени даты. @@CalcDate и @@CalcDateLast - глобальные переменные, доступные в любой сессии к БД и хранящие первый и последний день текущего расчетного месяца (глобальных переменных в БД много и они автоматически инициализируются сразу при подключении соединения на уровне СУБД. Есть даже переменные флаги признака наличия супервизорских прав или отладочного режима для текущего соединения).

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

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

Далее больше пойдет для Циничный Кот
Меня можно обвинить в усложние постановки, однако изначально задача ориентировалась как тиражный продукт, распостраняемый по многим уголкам страны (есть очень крупные заказчики на Севере, есть в Москве, есть и на Юге). Согласитесь при таких условиях изначально к проекту предьявлялись следующие требования: скорость из за крупности многих заказчиков, многофункциональность из за различной специфики работы во многих отраслях и легкость в сопровождении из за географической удаленности клиентов.

Если бы меня наняли делать калькулятор для расчета зп в мелких конторах с численностью до 500 человек, то я бы просто на такой проект и не согласился по той причине, что написано их предостаточно и ничего интересного в кач-ве опыта проектирования БД я бы для себя не приобрел.

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

Varivan
Книжек про безнадежные проекты читал не мало и кстати имею опыт в построении сложных систем, даже с недостаточной постановкой или ограничением ресурсами. Всего мной за 12 лет работы было написано 3 крупных проекта, каждый писался порядка 2 лет и прошу заметить они все до сих пор работают без моего личного участия. В той ветке форума я высказал опасения действиями своего руководства, игнорирующими изменения в условиях написания проекта. Проект я не могу считать безнадежным по следующим причинам:
1. Не смотря на нежелание выделить дополнительные ресурсы для форсирования проекта, фирма кровно заинтересована в его написании, так как старый расчет зп написан на ДОСовом Си, работает у кучи клиентов, использует для работы 640 кб (ох и времечко веселое было :) ), уже сложно поддается сопровождению и постоянно висит угроза увольнения программиста, его сопровождающего, так как рано или поздно все это ему надоест.
2. Фирма работает еще в другой отрасли и дела там пошли не самым лучшим образом (потери крупных клиентов), наверное из за излишней самоуверенности руководства, что означает востребованность в конторе достаточного крупного и перспективного проекта в кач-ве тыла.
3. Не смотря не на что мы пережили смену руководства, деньги нам платят исправно, желание писать проект не остыло.

Фактически если дословно привести сообщения с форума Работы я в соотвествующем форуме заметил, что мои работодатели явно странные люди, если видя что их основной на данных момент проект рушиться, вместо того, чтобы форсировать разработку запасного варианта, забирают у меня сотрудника, который отвечал за разработку отчетов и начинают перекидывать все материальные и людские ресурсы на гибнущий проект, периодически все таки выхватывая людей из команды зп на свои нужды. В итоге их проект поглощает все как черная дыра и продолжает исправно тонуть по той простой причине, что писался по той формуле, которой тут многие и советовали - сляпать за полгода основной функционал, запустить и потом дорабатывать. Так все и было - за полгода было сляпано нечто, изначально с не продуманной архитектурой, что потом в течении 4 лет исправно обрастало притыками и заплатками. Теперь условия постановки изменились, плюс я бы сказал был достигнут некий критический предел, когда приткнуть там уже новую функциональность не куда и проект при попытке его переработке просто "рухнул". Я бы на такие проекты вешал табличку - "Не трогай, а то упадет". Сразу вспоминается анекдот про отца-программиста, сына и солнце.

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

P.S. Кстати для справки - официально я занимаю должность ведущего разработчика, а не руководителя проекта, в роли которого себя считает начальство, так что обвинять меня как плохого руководителя бестолку - я им не был и не хочу быть. Если мне и приходится предпринимать какие то действия в "политике" предприятия, то они обуславливаются только моим желанием успешно дописать и запустить проект, и фактически осуществляются только благодаря моему "авторитету" на фирме и важностью проекта.

Уф, ей богу - хватит политики. Будем надеятся, что все будет хорошо и проект успешно начнет работать, приносить деньги фирме, уверенность клиентам и легкость в сопровождении программистам. Ну а мне будет достаточно соотвествующей галочки в резюме :)

Завтра постараюсь описать вышеобещанные мною реализации частей проекта, если конечно время позволит. Спасибо за участие и критику тоже (только желательно конструктивную) :)

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

Теперь отвечу:
Проект считается тиражным продуктом, который продается и сопровождается, разрабатывается все это в софтверной компании.

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

В принципе я выяснил уже после старта проекта, что до меня на протяжении 3 лет уже предпринимались 2 попытки переписать проект, в том числе и программистом, сделавшим старый ДОСовый расчет и отлично знающим все ньансы постановки. Где то после года-полтора работы проекты умирали по причине их ступора. Я раскопал эти проекты и проанализировав их остановку пришел к выводу, что главная их ошибка была в том, что проектирование велость модульно, т.е. по ходу работы, в итоге где то как раз через год работы после разработки соотвествующих входящих форм разработчики этих проектов упирались в сам расчет заработной платы и там дело и останавливалось по причине того, что структуры БД проектировались с соотвествующих входящих данных без учета взаимодействия с расчетной частью и связи с другими частями системы. Это приводило к тому, что при такой архитектуре расчеты должны были реализовываться курсорами и ветвлением, как и в старой зп, что приводило к тормознутости системы, или же при попытке использования для расчетов SQL разработчики сталкивались с сложным доступом к данным, используемых расчетом и не имея достаточно опыта не могли написать реализацию.

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

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

Если учесть все вышесказанное, то получается, что по постановке проект реализован чуть более половины, а по разработке технологий и решений встречающихся в его постановке проблем на 80% (оставшиеся 20% это системы экспорта данных и конверторы). Так что срезать что то и уж тем более резво запустить такой проект с учетом постановки и уже реализованного функионала уже не реально. Сама архитектура БД не позволит использовать ее как БД под примитивный калькулятор и любое дописание функционала проекты по любому просто будет обязанно придерживатся разработанных нотаций и правил системы.

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

c127
С учетом того, что у меня наглым образом отняли человека, сейчас нас два программиста, плюс 3 сопровождающих старую зп и выступающими консультантами, плюс девушка программистка со старой зп, выступающая консультантом и тестером, плюс 2 постановщика бухгалтера. Все кроме нас естественно не задействованны постоянно в проекте и привлекаются по мере надобности. Я получается являюсь головой проекта, на мне полностью БД и ядро и утверждение интерфейса клиентской части, плюс системные функции и иеархии обьектов генератора отчетов . Мой коллега держит на себе написание форм и логики клиентской части, и теперь разработку отчетности, раз нас стало двое. Вообще в общей сложности у меня "отняли" уже троих человек, причем один из них (главный постановщик и бывший программист-сопровождающий старый проект) уехал в Австралию, другой (программист) после полгода работы устроился на прекрасно оплачивуемую работу, теперь вот еще человека перевели на другой проект. Я конечно ничего против не имею, если народ решил уйти, но ведь нельзя же на освободившиеся ставки набирать сотрудников на работу в другом проекте, а потом иногда невинно у меня спрашивать - "Когда деньги то лопатой грести будем?". Я как человек честный предупреждаю конечно о возможных последствиях таких вольностей, когда общая численность старой и новой команд зп вместо бывших раньше 80% сотрудников конторы теперь занимает 5% от общего числа ее сотрудников, но все равно согласитесь не приятно, если руководство угробит фирму или проект, и мне придется делать выбор между уволиться и обьяснять на новом месте работы, что мне помешало запустить проект или же найти заинтересованных лиц и продолжать разработку проекта, раз уж так много сделано.

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

Во вторых я все таки не понимаю 3-звенщиков, которые всегда уверены, что они смогут написать сложную обработку данных быстрее, чем это реализовано на СУБД. То ли они не признанные гении, то ли просто никогда с SQL не работали. Если Вы действительно прочитали всю ветку, то правильно решили, что вообще все происходит именно в БД и от клиентской части никак не зависит. Так же можно было бы обратить внимание, что вся логика спроектирована и реализована посредством выборок, курсор в БД проекта - это исключение из правил и применяется в крайних, важно необходимых случаях. Плюс выше уже обсуждалось, что в такой задаче запросы всегда будут выполняться быстрее, так как увеличение обьема хранилища данных для выборок будет автоматически оптимизироваться на уровне СУБД, в случае же с отдельным звеном приведет к увеличению кол-ва обращений к БД и увеличению цикла расчета. И при чем тут железо не понимаю ? Зачем делать медленно для большинства заказчиков с обьемом расчитываемых данных (общий случай), чтобы потом это работало быстро на некоторых заказчиках с крупным обьемом данных (частный случай) ? Вы знаете, что те, у кого работают от 50 000 сотрудников не настолько бедны, чтобы не поставить себе нормальное железо, не заморачиваться, а заодно при желании купить и контору, сделавшую продукт в кач-ве бонуса сопровождения ?

P.S. Кстати - на вопрос данной темы я ответил полностью, раскрыв методику реализации системы с изменяющимеся алгоритмами расчетов и работающих за определенные периоды времени, реализованную с использованием только средств SQL сервера. Может быть 3-звену хватит меня критиковать и описать свои способы решения этой задачи с помощью их методологий ? Будет интересно посмотреть и сравнить, а уж полезно всей общественности, предпочитающей все равно сколько звеньев :) Так что с нетерпением жду описание реализации любой похожей на заданные условия задачи ....

Угу, извиняю :)

Кстати насчет абстракций - если рассматривать SQL, то абстрактней языка запросов ничего нет, так что Вы зря его называете кошмарным. Фактически я описываю на нем задачу, реализация же на выборку и обработку данных полностью ложиться на плечи СУБД. Если в новой версии СУБД производитель добавит новые технологии оптимизации обработки данных, мне ни на йоту не придется ничего переписывать и если бы в свое время производители СУБД не "поехали" в разные стороны, расширяя кто как хочет стандарт SQL, то скрипты БД были бы полностью абстрактны и в отношении любых серверов СУБД.

Еще дополнение - зп не большая, а сложная система. У любой системы должны быть границы. Чисто теоретически я мог бы изначально проектировать зп для расчета заработной платы всех жителей Китая, но такой задачи слава тебе господи и не ставилось :) Я же не утвержал, что всю бизнес-логику буду запихивать для биллинговых например систем. Я пытаюсь сказать другое - нельзя кидаться из крайности в крайность и проектировать задачи надо согласно фактическим требованиям системы, а не теоритическим "вот если". Если система будет большая и распределенная, то я согласен, в таких условиях по стоимости и скорости многозвенная архитектура катит. Если система со средним обьемом данных и вписывается в пределах реализации бизнес-логики на СУБД, то и не за чем огород городить. Однако у нас полно народу, которые насмерть стоят и все программируют в одном русле. Причем когда пытаешься выяснить мотивацию, то оказывается, что просто по другому программировать не умеет. Я тоже могу сказать, что не буду делать свои системы, как Вы и только по тому, что специализируюсь в своей области, а Вы в своей. Все логично и правильно - у меня хватает ума не брать проекты, которые явно требуют многозвенной архитектуры, Вы не связываетесь с проектами, где многозвенка явно не нужна. Соотвествующе и критиковать Вас или меня бестолку - у каждого своя ниша работы, обе технологии имеют право на жизнь. С другой стороны согласитесь описанный мой способ реализации расчетных алгоритмов просто и удобен и даже в многозвенной структуре при желании он может найти свое применение. Никто же не говорил, что технологии обработки данных не могут перемешиваться и обязательно должны быть чистыми.