Существует ли какая-либо библиотека / инфраструктура для отмены / повторного изменения строк в базе данных?

Question

Может быть, мой заголовок не понятен. Я ищу какой-то контроль версий для таблиц базы данных, как Subversion для файлов, как вики.

Я хочу отследить журнал изменений. Я хочу извлечь и запустить diff в обратном порядке. (отменить как "svn merge -r 101: 100"). Возможно, мне понадобится индексированный поиск по истории.

Я прочитал « Шаблон проектирования для Undo Engine », но он связан с «Шаблонами». Есть ли что-нибудь, что я мог бы использовать повторно, не изобретая велосипед?

EDIT: Например, транзакции по банковскому счету. У меня есть столбец "баланс" (и другие), обновленные в таблице. пользователь обнаружит ошибку через 10 дней и захочет отменить / откатить определенную транзакцию, не изменяя другие.

Как я могу сделать это изящно на уровне приложения?

Answer 1

Вы можете использовать подход пересмотра для каждой записи, которую вы хотите отследить. Это будет включать сохранение строки в вашей таблице для каждой редакции записи. Записи будут связаны друг с другом общим идентификатором и могут запрашиваться в «Статусе редакции» (например, получить последнюю «утвержденную» запись).

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

[ID] [Revision Date] [Revision Status] [Modified By] [Balance]
1     1-1-2008         Expired           User1         $100
1     1-2-2008         Expired           User2         $200
2     1-2-2008         Approved          User3         $300
1     1-3-2008         Approved          User1         $250

Answer 2

Мартин Фаулер освещает тему в Шаблоны для вещей, которые меняются со временем . Все еще шаблоны, а не фактическая структура, но он показывает пример данных и как их использовать.

Answer 3

педантичный пункт. Ваш пример банковского счета не пройдет мимо аудитора / регулятора.

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

Answer 4

Мне неизвестен конкретный шаблон, хотя я настроил полные истории отмен / аудита перед использованием триггеров и версий строк.

Существует несколько приложений для MS Sql, которые позволяют вам просматривать журналы и видеть реальные изменения.

Я использовал журнал Log Navigator в MS SQL 2000, который позволял мне отменить определенную историческую транзакцию - хотя я не могу найти ее сейчас.

http://www.lumigent.com и http://www.apexsql.com делают инструменты для просмотра журналов, но я не думаю, что и вы можете откатить их назад.

Я думаю, что лучший способ сделать это - написать ваше приложение, помня об этом - у вас уже есть несколько хороших советов о том, как это сделать.

Answer 5

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

Обычно вы добавляете столбцы с действительной датой и с текущей датой в каждую таблицу.

«Текущая» запись всегда должна иметь valid_to_date «2999-12-31» или какое-либо произвольно высокое значение. Когда значение изменяется, вы меняете «действительный на дату» на текущую дату и вставляете Новая строка с текущей датой сегодняшнего дня и текущей датой 2999-12-31 копирует все столбцы из старой строки, если они не были изменены.

Вы можете создавать виды с msgstr "выбрать все столбцы, за исключением действительных-xx-даты из таблицы, где действительные до даты = '2999-12-31'"

Что позволит всем вашим текущим запросам работать без изменений.

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

Логика отмены должна быть очевидной.

Answer 6

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

Существует довольно много тонкости в таком дизайне базы данных, но есть очень хорошая книга на эту тему:

Ричард Т. Снодграсс (Richard T. Snodgrass): разработка ориентированных на время приложений баз данных в SQL

доступно для скачивания здесь:

http://www.cs.arizona.edu/people/rts/tdbbook.pdf

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

Все, что находится на уровне приложения, если только оно не имеет какого-либо механизма персистентности, не сможет выжить после перезапуска приложения (хотя это может и не быть обязательным).

Answer 7

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