авторзадача впринципе обозначена была в первом сообщении...
авторучетные системы.

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

Для налогов и других начислений нужна таблица
авторПериод начислений (месяц)
Налог
Сумма

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

авторсами же начисления, которые вы имеете ввиду должны инициироваться исходя из установленных свойств у сотрудника.

Совершенно верно, и каждое из этих свойств имеет конкретное значение в определенном промежутке времени. Так в ведите в свои таблицы понятия промежутка времени и будет вам "история".

Запрос свойств "на позавчера" не должен ничем отличаться от запроса свойств "на текущий момент". Кроме указания периода времени (расчетного месяца к примеру)


авторэто уже результат расчета в виде журнала
Игрете словами. Журнал, не журнал, какая разница.
Важно привязывать выплаты и удержания к периоду расчета.

авторДля сущности "налог" нужна история баз (какие начисления входят в налоговую базу).

Пожалуйста.
Делаем таблицу видов оплат и таблицу налогов (на самом деле налоги можно рассматривать как частный случай вида оплаты).
В таблицу отношения многие-ко-многим добавьте поля "дата с.." и "дата по..".
Поверьте, многое упростится :)

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

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

авторКак одно из самых неприятных - отказ от ссылочной целостности на уровне БД.
О чем вы говорите?? Зачем, какой отказ???

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


авторпри этом хочу определенным ролям запретить на уровне слоя хп менять историю определенных атрибутов.
И этому нет припятсвий!

авторхочу иметь возможность хранить 2-х уровневую историю (история истории) - опять таки нужна для расчетов.

История ради истории, "потому что нужно".
Вы как будто в плену какой-то парадигмы и не хотети видеть иного.

авторкакие записи и в какой таблице будут если должность сотрудника
с 01.01.2006 по 31.01.2006 инженер
с 01.02.2006 по 31.12.2007 ведущий инженер

Незнаком с конкретно вашей реализации, так что будем терпимы друг к другу :)
Если говорим просто о названии шт. должности, то это можно поместить в таблицу
Сотрудник_К_ШтДолжности. Причем именно так, как вы нарисовали.
автор

допустим сегодня 01.03.2006
в истории оклада для сотрудника установлено что
01.01.2006 - 31.01.2006 оклад 100р.
01.02.2006 - 28.02.2006 оклад 200р.
теперь 01.03.2006 обнаруживается что 01.01.2006 - 31.01.2006 оклад должен быть 150, а не 100, но расчеты уже завершены.
Будете считать оклады с начала года как налоги?

Да, буду, пересчитывать с месяца, за который произошло изменение.
При расчете ЗП изменения задним числом вносятся часто.

сколько записей засторнировать придется?
Какую проблему я не вижу?

Извините, недописал предыдущий пост
авторколько записей засторнировать придется?

Какую проблему я не вижу?
Сколько надо, столько прога и просторнирует.

С уважением.

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

Давайте обсудим, в чем недостатки? В раздутости таблиц? Но для ЗП нужны данные за предыдущие периоды, это факт.

И о какой утрате ссылочной целостности вы упоминали?