Каков наилучший способ восстановления (отката) данных в приложении до указанного состояния (даты)?

Question

Пример установил бы право контекста, пример ниже захватывает различные состояния объекта, который должен быть возвращен (откат).

Состояние 1 - зарегистрировано 01 марта 2010 года

Column1 Column2
Data1    0.56

Состояние 2 - зарегистрировано 02 марта 2010 года

Column1 Column2
Data1    0.57

Состояние 3 - Зарегистрировано 03.03.2010

Column1 Column2
Data1    0.58

Пользователь замечает, что state3 - это не то, в чем он собирался находиться, и решает вернуться обратно в state2.

Один из подходов, который я могу придумать, без изменения сущности, заключается в «аудите» всех вставок / обновлений, как показано ниже, информация отката собирает данные непосредственно перед обновлениями / модификациями сущности, так что она применяется в порядке, когда вам нужно вернуться. Обратите внимание, что изменение схемы объекта не является вариантом.

Откат - R1, записанный 01 марта 2010 года

Column1 Column2
Data1    0.56

Откат - R2 Записано 02 марта 2010 года

Column1 Column2
Data1    0.56

Откат - R3 Записано 03 марта 2010 г.

Column1 Column2
Data1    0.57

Итак, чтобы перейти к состоянию2, мы начнем с информации отката R1, применив к нему R2.

Есть ли лучший подход для достижения этого?

Спасибо за ваше время.

Answer 1

Просто обновите текущее значение / состояние до требуемого значения / состояния.

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

Ваша сущность E1, имеющая состояние S3, могла быть необходимым условием для того, чтобы какой-то другой сущности E2 было разрешено иметь некоторое состояние Sx, которое может быть «несовместимо» с E1, имеющей состояние S1.

Если откатить E1 до прежнего состояния S1 без каких-либо действий с E2, база данных станет несовместимой.

Answer 2

Для каждой таблицы в вашей схеме создайте новую таблицу аудита в другой схеме с двумя дополнительными столбцами: validFrom и validTo.

Когда вы вставляете / обновляете строку, вам нужно внести два изменения в таблицу аудита:

update auditTable set validTo = sysdate where validTo is null
insert auditTable ...copy-of-all-columns..., validFrom = sysdate

(без вставки, если вы удаляете строку в исходной таблице).

Если вам необходимо вернуться к определенному состоянию, вы можете выбрать строку в таблице аудита с тем же первичным ключом (PK), которая находится в диапазоне времени [ validFrom, validTo ) или где validTo is none, и просто скопировать строка в исходную таблицу.

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

Answer 3

Что вам нужно, так это механизм, подобный Linux ext3 - журналы. (Я не уверен, но это может быть модель ZFS для файловой системы Solaris, но это не главное)

Их идея состоит в том, чтобы хранить журнал для каждого файла (понять его объект / запись / ...), и каждое изменение, которое происходит с ним, создает другую точку входа, хранящую только изменения , таким образом, у вас нет репликация. У вас есть простой и быстрый откат - вы просто говорите, что хотите выполнить откат до 6 версий в обратном направлении, а Файловая система выполняет следующие действия:

удаляет последние 6 версий и помечает currentVersion-6 как самую последнюю, и вы готовы.

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

Вы можете сделать что-то подобное для БД. Как вы это нашли? Я видел это в действии на Solaris с ZFS, и он работает очень быстро, и эта файловая система была награждена в прошлом году (или 2008 ...?) За очень высокое качество.

Answer 4

Это может не подходить для приложения, управляемого БД, но общий шаблон проектирования, который может помочь, - шаблон Memento:

http://en.wikipedia.org/wiki/Memento_pattern

Answer 5

Вместо «применения» обновлений вы можете иметь поле или отдельную справочную таблицу, которая будет указывать на «текущее» состояние объекта. Таким образом, откат будет означать перемещение флага или изменение ссылки на другую сущность в таблице аудита.