mcureenabДля расчёта ЗП тонкий клиент нафиг не нужен (разве что ваш бухгалтер предпочитает вести дела не в офисе, а в непринуждённой обстановке на природе или между прочим в интернет кафе), тем не менее грамотное распределение обязанностей между клиентом и сервером, а может быть и сервером приложений никто не отменял. Не исключено, что имеет смысл создать отдельный сервер для расчёта ЗП, чтобы не нагружать сервер выполнением хранимых процедур.
Короче, выбирай архитектуру приложения исходя из решаемой задачи, а не деталей реализации.
А можно создать еще сервер для предрассчета ЗП, чтобы он снял нагрузку с сервера расчета ЗП - ефиг ему заниматься всякими подготовительными данными, типа скока часов проработали сотрудники и т.д., это все предрассчетный сервер пусть делает
авторТриггеры БД. Но лучше продумать структуру БД так, чтобы обновлять другие таблицы не было надобности. Исключением могут быть операции протоколирования изменений и т.п. однотипные системные действия. Тогда все триггеры можно будет сгенерить по шаблону.

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

2 izoldov-roskini
Пиши через хранимые процедуры и никого с экзотическими рассуждениями не слушай - думаешь все правильно. Так и надо делать, чтобы потом не иметь проблем с изменением бизнес-логики и т.д. Клиент - отдельно, бизнес-логика - отдельно, меняется и то и то независимо.


-- Tygra's --
Мои фотогалереи тут и тут