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

Насчет - через Ж..У:
Категорически не согласен. У меня движок расчетов работает по принципу Расчет по требованию и может посчитать в любой момент обращения клиента к расчетной информации, причем даже отдельное начисление/удержание. Фича полезная - в любой момент расчетчик может посмотреть, чего там на чела выходит (например при распределении премий между отделами гораздо удобнее их выставлять и сразу видеть, сколько кому получается). Скорость кстати не страдает, так как все результаты расчетов сбрасываются и сохраняются в расчетном кэше, который отслеживает изменения в БД, помечая не только какие договора поменялись и их надо пересчитать, но и вплоть до того, какие расчетные статьи поменялись. Для правильной работы расчета сюда же приплюсуйте систему отношений (dependenced), которая ответственна за поддержку иеархии между статьями нач/удерж. В итоге даже если у вас расчет для всех людей пройдет в начале месяца, и вы всему одному договору измените условия - например поставите премию, то при закрытии расчетного месяца досчитается именно этот договор, причем считаться будет именно эта премия, а пересчитается только то, что на нее завязано (подоходний, ...). Кстати весь движок расчетов, вплоть до механизма пользовательских нач/удерж писан на TSQL и довольно таки шустро работает несмотря на универсальность - полный расчет 1000 договоров занимает где то 20 сек.

funikovyuri:
Интересно, как написать запрос на 2 таблицы, если они никак между собой не соединяются ? По идее у Вас в обоих таблицах присутствует как я понял код служающего. Других связей я предположить не могу.