Есть ли библиотека / рамки для отмены / повтора изменений строк в базе данных?

голоса
2

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

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

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

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

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

Задан 09/12/2008 в 15:08
источник пользователем
На других языках...                            


7 ответов

голоса
2

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

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

[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
Ответил 09/12/2008 в 16:40
источник пользователем

голоса
2

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

Ответил 09/12/2008 в 16:19
источник пользователем

голоса
1

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

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

Ответил 09/12/2008 в 16:05
источник пользователем

голоса
0

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

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

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

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

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

Ответил 10/12/2008 в 11:20
источник пользователем

голоса
0

На основании различных комментариев возможное решение вашей проблемы было бы сделать «дату эффективной» таблицу.

Основном добавить действительные-с современными и действительные современные столбцы каждой таблицы.

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

Вы можете создавать представления с «выбрать все-колонки-кроме недействительной-ой-даты из таблицы, где действует актуальный =„2999-12-31“»

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

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

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

Ответил 10/12/2008 в 11:07
источник пользователем

голоса
0

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

Там изрядное количество тонкости в такую ​​конструкцию базы данных, но есть очень хорошая книга по теме:

Разработка Time-ориентированных баз данных приложений в SQL Ричард Т. Снодграсс

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

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

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

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

Ответил 09/12/2008 в 18:02
источник пользователем

голоса
0

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

Ответил 09/12/2008 в 17:05
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more