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