hVosttАнатоЛойпропущено...

Эт-то почему же? :)

Нет нужды для ретроспективы.
Непонятно. Зачем тогда вообще логировать просмотры?

hVostt,
1. Ведём две БД: операционную (ОБД) и историческую/версионную (ИБД).
2. Запросы на чтение к ОБД и ИБД от слоя бизнес-логики одинаковы, но проходят "препроцессорную" обработку.

3. Структуры ОБД и ИБД синхронизированы с небольшими поправками:
3.1.У каждой таблицы в ОБД есть поле id - первичный ключ таблицы.
3.2.Для каждой таблицы из ОБД в ИБД последовательно сделано:
0) создана копия структуры таблицы;
1) удалены ограничения целостности;
2) восстановлены все сопровождавшие эти ограничения индексы (уникальные индексы преобразованы в неуникальные);
3) добавлены доп. поля:
а) id_original - заполняется значением первичного ключа таблицы в ОБД (но не является альтеративным ключом в ИБД!).
б) id - autoinc, первичный ключ в ИБД.
в) timestamp - дата и время добавления записи в ИБД.
г) is_operation - признак операции CUD в ОБД, приведший к появлению записи в ИБД.
5) все внешние ключи в ИБД восстановлены как в ОБД, но ссылаются не на поле id_original, а на поле id.

4. При любом CUD в ОБД делаем асинхронный insert в ИБД, при котором:
для значения каждого внешнего ключа в записи выполняется поиск в связанной таблице актуальной записи на дату этого insert (можно подумать просто про последнее значение - но сейчас лень).

5. Все запросы при обращении к полям используют препроцессорные вызовы функций:

1) обращение к полю первичного ключа таблицы %ActualPK(<table>)%
2) обращение к значению поля со вторичным ключом %ActualFK(<table>.<field>)%
3) обращение к значению поля для сравнения с константой

Например:

X) SELECT a.*, b.*
FROM a join b on %ActualPK(a)% = %ActualFK(b.a_id)%

Y)
SELECT a.name
FROM a
WHERE %ConstCompare(a.field_name)% LIKE 'Вау*'

6. Примеры разворачивания запросов:

X.ОБД) В ОБД препроцессор делает следующее:

SELECT a.*, b.*
FROM a join b on a.id = b.a_id;

Y.ОБД)
SELECT a.name
FROM a
WHERE a.field_name LIKE 'Вау*'


В ИБД у всех шаблонов есть некая константа "точка прошлого" для сессии типа дата-время.

X.ИБД)
Шаблон разворачивается:
SELECT a.*, b.*
FROM a join b on GetActualId(a.id_original, %history_time_point%) = b.a_id AND b.id IN (GetActualIds(b, %history_time_point%))

Y.ИБД)
SELECT a.name
FROM a
WHERE a.field_name LIKE 'Вау*' AND a.id IN (GetActualIds(а, %history_time_point%))

Производительность может быстро оказаться в Опе, но это уже другая история :).

АнатоЛой, ой-ой, пару ошибок, в реализации, но думаю, что суть понятна :).

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