_модkarapetyan_aЯ пока решаю подобные вопросы добавляя 2 поля типда DateTime: BeginDate, EndDate. т.е. Время валидности данной записи, но тогда использование таких таблиц ( тем более связанных друг с другом ) сильно усложняется........ может кто подскажет другие варианты решений подобных задач?
Ну это просто. А вот изменение самой структуры таблицы во времени как отслеживать ?
Я использую EAV с историей.

Если из таблицы поля не удалять (т.е. по сути не удалять данные, без которых старый отчёт не получится), то и старому отчёту болжно быть фиолетово, что в структуре таблицы изменилось. Он просто возьмёт из БД то что ему нужно.

Хуже, когда речь идёт о миграции данных в новую схему. Далеко не всегда находятся ресурсы, чтобы дорабатывать унаследованные отчёты и т.п. модули, которые сейчас уже не используются. Остаётся сохранить старую систему, чтобы при нужде вытянуть из неё архивные данные.

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

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

Наконец "повторяемость" результатов расчёта иногда трактуют неверно. В ряде случаев это означает только то, что на одних и тех же данных, должны получаться одни и те же результаты (тогда и вся эта канитель ни к чему). Если вам нужно просто получить старый отчёт, независимо от того, что БД могла поменяться, то сразу сохраните его в виде файла и не мучайте БД.